Storage account secure transfer required is the switch that tells Azure Storage to refuse unsafe HTTP traffic. When it is enabled, clients must use HTTPS for storage requests, so credentials, SAS tokens, and data are not sent over clear text. It is normally a baseline setting for production accounts, especially when blobs, queues, tables, or files contain business data. Disabling it is rarely justified and should be treated as an exception with a clear workload reason, compensating network controls, and an expiration date.
Storage account secure transfer required, storage account secure transfer required, storage-account-secure-transfer-required, secure transfer required, HTTPS only storage, enableHttpsTrafficOnly
Difficulty
fundamentals
CLI mappings
5
Last verified
2026-05-25
Microsoft Learn
Storage account secure transfer required is an account setting that rejects non-secure requests to Azure Storage. When enabled, REST calls must use HTTPS, helping protect authentication material and data in transit from exposure or network interception. It is commonly enabled by default and governed through policy.
Technically, secure transfer required is a control-plane property on the storage account, commonly surfaced as enableHttpsTrafficOnly in resource output and --https-only in Azure CLI. It affects data-plane requests by rejecting insecure transport before normal service processing. The setting belongs with minimum TLS version, public network access, firewall rules, private endpoints, and encryption requirements. It is often governed through Azure Policy because teams need consistent transport security across subscriptions. Operators inspect it through ARM, Bicep, CLI, portal security settings, and compliance dashboards.
Why it matters
Secure transfer required matters because storage credentials are powerful and often travel with automated workloads. A single HTTP path can expose SAS tokens, shared keys, authorization headers, or sensitive payloads to interception on untrusted networks. Even if most clients already use HTTPS, the setting provides a fail-closed guardrail when someone deploys old code, copies an insecure URL, or misconfigures a third-party integration. It also supports compliance evidence by turning a recommendation into an enforceable account behavior. For platform teams, it is one of the simplest storage controls to standardize: enable it, deny drift with policy, and investigate any exception immediately.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In the storage account Configuration blade, Secure transfer required appears as a baseline security setting that should normally remain enabled for production and regulated data.
Signal 02
In Azure CLI or ARM output, the enableHttpsTrafficOnly property shows whether the account rejects plain HTTP storage requests before normal service processing across deployments safely.
Signal 03
In Azure Policy compliance results, built-in storage policies can flag or deny accounts where secure transfer is disabled across subscriptions, management groups, or landing-zone baselines.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Enforce HTTPS-only access across production storage accounts to reduce credential and data exposure in transit.
Find legacy integrations that still depend on HTTP before policy enforcement turns them into outages.
Prove to auditors that storage accounts reject insecure transport instead of relying on developer convention.
Standardize storage account creation in Bicep, Terraform, or CLI so new accounts cannot drift from baseline security.
Investigate Defender for Cloud or Azure Policy findings that report secure transfer disabled on sensitive accounts.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
University lab removes HTTP from research exports
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A university research lab discovered that an old data exporter still sent sample metadata to Blob Storage through HTTP URLs copied from legacy scripts.
🎯Business/Technical Objectives
Block insecure storage requests without interrupting active experiments.
Find every exporter using http:// storage endpoints.
Update pipeline templates to deploy HTTPS-only accounts.
Produce compliance evidence for the research security board.
✅Solution Using Storage account secure transfer required
The platform team first used Azure CLI to inventory enableHttpsTrafficOnly across research storage accounts and flag disabled accounts. Logs and source repositories were searched for http:// storage endpoints, and the lab updated the exporter SDK and connection settings. Secure transfer was enabled in a test subscription, then enforced on production accounts during a maintenance window. The Bicep module was changed so new accounts set HTTPS-only by default, while Azure Policy audited any future drift. CLI output and rejected HTTP test requests were attached to the compliance packet. A rollback plan covered only the exporter service, so unrelated research jobs were not delayed.
📈Results & Business Impact
Thirty-seven legacy HTTP references were removed before enforcement.
No active experiment jobs failed after the production switch.
All new research accounts deployed with HTTPS-only enabled.
The security board closed the transport finding two weeks early.
💡Key Takeaway for Glossary Readers
Secure transfer required turns an expected best practice into an enforceable guardrail that catches old clients before they leak data.
Case study 02
Construction SaaS tightens partner document uploads
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A construction management SaaS provider accepted project documents from subcontractor tools, and one partner still used an insecure upload endpoint.
🎯Business/Technical Objectives
Require encrypted transport for all partner uploads.
Keep upload success above 95 percent during migration.
Document partner exceptions and deadlines.
Prevent engineers from disabling the setting during support calls.
✅Solution Using Storage account secure transfer required
The operations team created a subscription-wide CLI report showing which storage accounts had secure transfer disabled and which partner pipelines wrote to them. They enabled HTTPS-only in a staging account and gave the partner a test SAS URL using HTTPS. After confirming the partner tooling supported secure URLs, the team enabled secure transfer on the production account with az storage account update. A policy assignment then denied future accounts without secure transfer, and support runbooks were updated to treat HTTP upload failures as partner remediation issues, not reasons to weaken the account setting. A dashboard tracked partner readiness daily until enforcement completed.
📈Results & Business Impact
Partner upload success stayed at 98 percent during the migration week.
Insecure upload attempts dropped to zero after tooling updates.
Support escalations for rejected HTTP requests fell by 71 percent.
Policy prevented three later test accounts from launching with the setting disabled.
💡Key Takeaway for Glossary Readers
HTTPS-only storage access is easiest to maintain when partner onboarding, policy, and support behavior all reinforce the same baseline.
Case study 03
Insurance claims team passes transport security audit
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
An insurance claims processor needed to prove that storage accounts holding adjuster photos and claim PDFs rejected non-secure transport.
🎯Business/Technical Objectives
Verify secure transfer across all claims storage accounts.
Remediate exceptions before the external audit date.
Avoid exposing SAS tokens or keys in evidence files.
Align IaC templates with the audited configuration.
✅Solution Using Storage account secure transfer required
The cloud governance team built a CLI query that exported resource ID, account name, environment tag, and enableHttpsTrafficOnly for every storage account in claims subscriptions. Two disabled accounts were traced to old Terraform variables and remediated after client testing. The team updated templates, added a policy assignment at management group scope, and stored sanitized CLI evidence in the audit workspace. They also ran a controlled HTTP request against a test blob and captured the rejection result without including any real claim documents or secrets. The evidence pack linked each exception to an owner and closure date.
📈Results & Business Impact
All 184 claims storage accounts showed HTTPS-only before audit sampling.
Two template defects were fixed and backported to shared modules.
Auditors accepted sanitized CLI evidence with no secret leakage.
Quarterly compliance review time dropped from two days to three hours.
💡Key Takeaway for Glossary Readers
Secure transfer required gives auditors and operators a clear, testable answer to whether storage data-plane traffic can use unsafe HTTP.
Why use Azure CLI for this?
I use Azure CLI for this setting because transport security has to be verified at scale. In a real estate with hundreds of storage accounts, clicking through the portal is slow and unreliable. CLI lets me list accounts, project enableHttpsTrafficOnly, find exceptions, remediate with --https-only true, and export evidence for auditors. It also fits policy remediation and pipeline checks, where a build should fail before an insecure account reaches production. After years of operations, I have learned that simple baseline settings drift when nobody inventories them. CLI makes the baseline visible, repeatable, and easy to compare across tenants. That makes remediation safer and faster.
CLI use cases
Inventory storage accounts and export name, resource group, subscription, and enableHttpsTrafficOnly for compliance review.
Enable HTTPS-only transport on a specific account with az storage account update after client testing is complete.
Create new accounts with --https-only true so insecure transport is never accepted during initial deployment.
Combine CLI inventory with Azure Policy assignments to identify exceptions that need approval or remediation.
Compare production and development settings to catch teams that disabled secure transfer during testing and never restored it.
Before you run CLI
Confirm tenant, subscription, and resource group because enabling HTTPS-only can immediately reject existing HTTP clients.
Check application logs, partner integrations, and old connection strings for http:// storage endpoints before enforcing the setting.
Make sure you have Microsoft.Storage storageAccounts write permission if you plan to remediate, not just inspect.
Coordinate with security policy owners so manual changes do not fight deny or modify policy assignments.
Use targeted JSON queries and avoid printing connection strings, SAS tokens, or account keys while reviewing transport settings.
What output tells you
enableHttpsTrafficOnly set to true means the storage account rejects insecure HTTP requests to supported storage services.
A false value is a security exception that should be tied to a documented workload, owner, and remediation plan.
Policy output shows whether the account is audited, denied, or automatically modified by a secure-transfer governance rule.
Failed client requests after remediation often reveal hard-coded HTTP URLs, old SDKs, proxy issues, or partner tooling gaps.
Resource IDs in output help map exceptions to subscription owners, deployment pipelines, and change records.
Mapped Azure CLI commands
Storage account secure transfer CLI commands
direct
az storage account show --name <account-name> --resource-group <resource-group> --query enableHttpsTrafficOnly
az storage accountdiscoverStorage
az storage account update --name <account-name> --resource-group <resource-group> --https-only true
az storage accountsecureStorage
az storage account list --query "[].{name:name,resourceGroup:resourceGroup,httpsOnly:enableHttpsTrafficOnly}"
az policy state list --query "[?contains(policyDefinitionName,'secure') || contains(policyDefinitionName,'Secure')]"
az policy statediscoverStorage
Architecture context
Architecturally, secure transfer required is part of the platform security baseline for every storage account. It does not decide who is authorized, which networks can connect, or which TLS version is accepted, but it establishes the minimum expectation that data-plane requests use encrypted transport. I place it beside minimum TLS version, private endpoints, public network access restrictions, Defender recommendations, and policy assignments. The important architecture point is that this setting protects both human mistakes and automated clients. If an application still depends on HTTP, that is a design smell that should trigger migration planning, not a quiet exception. It belongs in every landing-zone baseline.
Security
Security impact is direct and high. When secure transfer is required, insecure HTTP requests are rejected, reducing exposure of tokens, account keys, headers, and payloads in transit. The setting does not replace identity controls, SAS expiry, private networking, encryption at rest, or minimum TLS enforcement, but it closes a common transport downgrade path. Exceptions should be rare, documented, and reviewed with security owners because they allow clear-text data-plane access. Azure Policy can audit or deny accounts that disable the setting, and diagnostic evidence should show any attempted insecure access. The safest posture is HTTPS-only by default. Treat disabled accounts as exceptions.
Cost
There is no separate charge for enabling secure transfer required, but the cost impact appears through migration and operations. Legacy clients may need code changes, certificates, SDK upgrades, or partner coordination. Policy enforcement can also uncover technical debt that takes engineering time to fix. The cost of leaving it disabled is harder to see but potentially much larger: leaked credentials, compliance findings, incident response, and data exposure. For FinOps and governance teams, the best pattern is to standardize HTTPS-only account creation so exceptions do not become recurring cleanup projects. Preventing insecure drift is cheaper than investigating every disabled account later.
Reliability
Reliability impact is indirect but real. Enabling secure transfer can break old clients, scripts, appliances, or integrations that still call storage over HTTP. That failure is desirable from a security view, but it can look like an outage if teams do not test before enforcing policy. Reliable rollout means inventory clients, inspect logs for HTTP requests, update connection strings, and deploy enforcement in stages where legacy workloads exist. Once enabled, the setting improves operational stability by removing ambiguous mixed-protocol behavior. During incident response, operators can focus on identity, networking, and service health rather than wondering whether insecure transport is still accepted.
Performance
Performance impact is usually minimal because modern storage clients already use HTTPS and TLS acceleration is expected. The setting does not change account throughput, partition limits, or redundancy. Performance concerns show up when legacy clients are forced to upgrade, when TLS inspection devices add latency, or when failed HTTP retries create noisy error patterns. Operators should monitor request failures after enabling the setting and separate expected rejections from real service latency. In most environments, enforcing HTTPS improves diagnostic performance: any HTTP attempt fails quickly and clearly instead of creating inconsistent behavior across applications, scripts, and partner integrations. This clarity helps troubleshooting under pressure.
Operations
Operators handle secure transfer as a baseline configuration item. They inspect enableHttpsTrafficOnly, remediate disabled accounts, attach policy assignments, and document any approved exceptions. Useful runbooks include a subscription-wide inventory, a change command to enable HTTPS-only, a query that finds newly noncompliant accounts, and a post-change test from representative clients. Troubleshooting usually means checking whether an application still uses http:// endpoints, old SDK settings, or hard-coded connection strings. For production, operators should track the change in release notes and confirm that monitoring, backups, ingestion jobs, and partner transfers continue over HTTPS after enforcement. Evidence should include owner and scope. Track approvals after each change.
Common mistakes
Assuming TLS is enforced just because connection strings usually contain HTTPS endpoints.
Disabling secure transfer to fix a partner issue without a time-bound exception and migration plan.
Forgetting to update IaC templates, causing every redeployment to undo the manual remediation.
Confusing secure transfer with minimum TLS version; both matter, but they enforce different transport controls.
Testing only application startup and missing background jobs, backup exports, or scripts that still use HTTP.