Secure transfer required means the storage account refuses insecure HTTP traffic. Applications, scripts, and tools must use HTTPS when they call Blob, Queue, Table, or File REST endpoints. It does not replace identity, firewall rules, private endpoints, or customer-managed keys; it simply makes the transport channel encrypted. For an operator, the setting is a quick yes-or-no control that proves data is not being sent to storage over clear text by mistake. It is a baseline guardrail, not a full storage security design.
HTTPS-only storage, enableHttpsTrafficOnly, secure transfer to storage accounts
Difficulty
intermediate
CLI mappings
4
Last verified
2026-05-23
Microsoft Learn
Secure transfer required is a storage account setting that rejects HTTP requests and allows Azure Storage operations only over HTTPS. It is enabled by default for new accounts and supports policy enforcement for teams that need encryption in transit across blobs, queues, tables, and files.
In Azure architecture, secure transfer required is a storage account control-plane property that affects data-plane requests. It sits beside network rules, public network access, minimum TLS version, shared key access, private endpoints, and Azure Policy. The property is usually deployed through ARM, Bicep, Terraform, Azure Policy, or Azure CLI. When enabled, Azure Storage rejects HTTP requests before normal authorization succeeds, so client configuration, SDK endpoints, SAS URLs, and legacy integrations must all use HTTPS. That behavior makes it both a deployment setting and a troubleshooting signal.
Why it matters
Secure transfer required matters because storage accounts often hold logs, documents, backups, lake files, queue messages, and application state. A single legacy client using HTTP can expose metadata or payloads to network interception, especially during migrations or hybrid integration. The setting gives platform teams a simple enforceable control: insecure transport fails rather than silently continuing. It also supports audit evidence because Azure Policy can report accounts where HTTPS-only transport is not enabled. The real operational value is preventing drift. New storage accounts, restored automation, and third-party tools must meet the same baseline before they can exchange data with production storage.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
You see secure transfer required in the storage account Configuration blade as the Secure transfer required toggle, usually beside TLS, shared key, and public access settings.
Signal 02
You see it in CLI or ARM output as enableHttpsTrafficOnly, where false values become easy evidence for policy remediation, exception reviews, or baseline drift reports.
Signal 03
You see it in Azure Policy compliance results when built-in storage policies flag accounts that still permit insecure HTTP requests during monthly governance reviews across subscriptions.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Block legacy HTTP storage calls during a migration before sensitive files, logs, or queue messages move into production accounts.
Prove encryption in transit for storage accounts during audits without relying on screenshots or manually sampled portal settings.
Enforce a landing-zone storage baseline with Azure Policy so new accounts cannot drift from HTTPS-only transport requirements.
Troubleshoot broken storage clients after security hardening by finding connection strings, SAS URLs, or SDKs still using HTTP endpoints.
Review exceptions for protocol-specific workloads and document compensating controls before temporarily allowing insecure transport behavior.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Logistics integrator removes insecure blob uploads from depot scanners
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A logistics integrator collected package photos from depot scanners that still uploaded to Blob Storage through old HTTP URLs. Security testing showed the traffic could expose image metadata on shared warehouse networks.
🎯Business/Technical Objectives
Require encrypted transport for every production storage request.
Find scanner firmware and scripts still using HTTP endpoints.
Avoid disrupting overnight depot uploads during the busiest shipping week.
Produce audit evidence for the customer data protection team.
✅Solution Using Secure transfer required
The platform team used Azure CLI to inventory storage accounts and confirm which ones had secure transfer required disabled. For the depot account, they enabled HTTPS-only transport in a staging account first, then ran scanner upload tests with updated firmware and regenerated SAS URLs. Azure Policy was assigned at the logistics subscription to audit any account without secure transfer required. Production enforcement was scheduled by depot region, with Application Insights alerts watching failed upload rates and storage logs confirming successful HTTPS requests. The runbook captured the previous setting, change ticket, owner approval, and post-change CLI output.
📈Results & Business Impact
All 37 depot scanners moved to HTTPS endpoints before the production cutoff.
HTTP storage requests dropped to zero within four days of staged enforcement.
Audit evidence collection fell from two days of screenshots to one CLI export.
💡Key Takeaway for Glossary Readers
Secure transfer required turns encrypted storage transport from a recommendation into a control that fails unsafe clients before data is exposed.
Case study 02
City records portal fixes audit finding without redesigning storage
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A city records office hosted public documents and internal redaction files in separate storage accounts. An audit found that one internal account still accepted HTTP because it had been created years earlier.
🎯Business/Technical Objectives
Close the transport-security finding before the next council review.
Preserve existing private endpoint and firewall controls.
Identify automation that could fail when HTTP requests were rejected.
Standardize storage creation rules for future departments.
✅Solution Using Secure transfer required
The cloud operations team queried all municipal subscriptions for enableHttpsTrafficOnly and grouped results by department tag. They updated the internal records account through Azure CLI after testing redaction jobs, export scripts, and backup validation against HTTPS endpoints. A deny policy was assigned for new storage accounts that did not require secure transfer, while a short audit-only phase gave departments time to find legacy clients. The records team added the CLI evidence, policy assignment, and a list of validated jobs to the audit packet. No public data architecture had to change because the issue was transport enforcement, not content access.
📈Results & Business Impact
The audit finding was closed two weeks before the council deadline.
Nine old scripts were corrected before enforcement, avoiding a records-processing outage.
New noncompliant storage accounts fell from 12 in the prior quarter to zero.
Evidence preparation time dropped by 70 percent for the follow-up audit.
💡Key Takeaway for Glossary Readers
A small storage account setting can solve a serious audit problem when it is verified across subscriptions and backed by policy.
Case study 03
Manufacturing analytics team hardens lake ingestion after vendor migration
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A manufacturing analytics group moved supplier quality files into Azure Data Lake Storage. One vendor transfer tool used HTTP-based Blob endpoints, creating concern before production ingestion began.
🎯Business/Technical Objectives
Enforce HTTPS for supplier file ingestion before go-live.
Keep private endpoint routing and managed identity access unchanged.
Create a repeatable preproduction check for new supplier accounts.
✅Solution Using Secure transfer required
Engineers cloned the target storage configuration into a preproduction account and enabled secure transfer required. They asked the vendor to retest uploads using HTTPS Blob endpoints and regenerated SAS tokens with short expiry for validation. Azure CLI checks were added to the release pipeline so any storage account with enableHttpsTrafficOnly set to false failed the deployment review. Because the lake also used private endpoints and ACLs, the team separated transport failures from authorization failures in the runbook. After testing, the production account kept HTTPS-only enforcement enabled from day one.
📈Results & Business Impact
Vendor upload failures were discovered and fixed five days before production launch.
No supplier files were transmitted over HTTP after go-live.
Release review time for new supplier storage accounts dropped from 90 minutes to 15 minutes.
The analytics team avoided an estimated two-week delay from late security rework.
💡Key Takeaway for Glossary Readers
Secure transfer required is most valuable when it is tested before go-live, not discovered as a broken client after production traffic starts.
Why use Azure CLI for this?
I use Azure CLI for secure transfer required because storage baselines have to be checked across many accounts, not just one portal page. CLI makes the HTTPS-only property visible in JSON, easy to compare against policy, and simple to update during controlled remediation. After ten years of Azure work, I do not trust screenshots for storage security evidence. I want commands that can list every account in a subscription, show enableHttpsTrafficOnly, export exceptions, and apply a change only after owner, region, private endpoint, and client impact are understood. It also lets policy teams rerun the same check after every deployment without waiting for manual review.
CLI use cases
Inventory every storage account where enableHttpsTrafficOnly is false and export the owner, region, and resource group for remediation.
Enable HTTPS-only transport on a named storage account after confirming client compatibility and change-window approval.
Compare storage account transport settings against Azure Policy compliance results to identify false assumptions or stale exceptions.
Validate a Bicep deployment by showing the property after release instead of trusting template intent alone.
Before you run CLI
Confirm the tenant, subscription, storage account name, resource group, and whether you are using a read-only inventory command or a mutating update.
Check for legacy clients, SAS URLs, automation jobs, appliances, or partner integrations that may still use HTTP endpoints before enabling enforcement.
Review storage firewall, private endpoint, minimum TLS, shared key, and policy assignments so one security change is not confused with another.
Use JSON output for evidence, and capture the old setting before changing anything that could break production ingestion or backups.
What output tells you
The enableHttpsTrafficOnly field tells you whether the account rejects HTTP requests and requires secure transport for supported storage operations.
Resource ID, location, kind, SKU, and tags help tie the setting to the correct workload, owner, environment, and exception process.
Policy output shows whether the account is compliant, denied, exempted, or still waiting for assessment after a remediation change.
Post-change output proves the property changed, but application logs still need to confirm that real clients can reach storage over HTTPS.
Mapped Azure CLI commands
Inspect and enforce secure storage transfer
operates
az storage account show --name <storage-account> --resource-group <resource-group> --query enableHttpsTrafficOnly
az storage accountdiscoverStorage
az storage account update --name <storage-account> --resource-group <resource-group> --https-only true
az storage accountconfigureStorage
az graph query -q "Resources | where type =~ 'microsoft.storage/storageaccounts' | project name, resourceGroup, enableHttpsTrafficOnly=properties.supportsHttpsTrafficOnly"
az graphdiscoverStorage
az policy assignment list --scope <scope> --output table
az policy assignmentdiscoverManagement and Governance
Architecture context
A seasoned Azure architect treats secure transfer required as a nonnegotiable storage baseline unless a rare protocol exception is formally approved. It belongs in the same design conversation as minimum TLS version, private endpoints, storage firewall rules, managed identity access, SAS governance, and diagnostic logging. The setting does not decide who can access data; it decides whether any request may arrive over an insecure transport. That makes it a guardrail around the data plane. In landing zones, I expect it in Bicep modules, Azure Policy assignments, and exception reporting so application teams cannot accidentally weaken storage transport during a rushed deployment.
Security
Security impact is direct. When secure transfer required is enabled, Azure Storage rejects HTTP requests and forces encrypted transport for supported storage operations. That reduces exposure to eavesdropping, session hijacking, and man-in-the-middle attacks on insecure networks. The setting does not prove the caller is trusted, so RBAC, shared key controls, SAS expiry, private endpoints, and firewall rules still matter. The main risk is disabling it to support an old client and never restoring the baseline. Any exception should name the account, protocol, workload owner, compensating network control, expiry date, and approval record. Reviewers should also confirm TLS baselines and logging stay aligned.
Cost
Secure transfer required has no separate meter and normally does not change the storage bill directly. The cost impact is mostly avoided risk and operational effort. Enforcing HTTPS can prevent costly security incidents, audit exceptions, and emergency client rewrites after a finding. There may be short-term labor cost when teams discover legacy jobs, appliances, or scripts that still call HTTP endpoints. Policy-driven remediation is cheaper than manual account-by-account review, especially across many subscriptions. FinOps owners should treat the setting as a baseline control whose expense is engineering cleanup, not a recurring Azure charge. The cheapest path is catching drift early.
Reliability
Reliability impact is indirect but real. Enabling secure transfer required can break clients that still use HTTP endpoints, old connection strings, or hard-coded URLs. That failure is intentional from a security perspective, but it still becomes an outage if nobody tested the callers. Reliable rollout starts with inventory, access logs, SDK versions, pipeline tests, and owner communication. After the setting is enforced, applications should retry over HTTPS and monitoring should watch for failed storage requests. The control also improves long-term stability because teams stop supporting insecure mixed-protocol behavior that complicates incident response and audits. Treat the rollout like a security change with a visible rollback decision.
Performance
Runtime performance impact is usually small because modern storage clients already use HTTPS. The practical performance issue appears during remediation: old tools may fail, retries may increase, or a pipeline may slow while developers update endpoints and credentials. TLS handshakes add overhead, but for Azure Storage this is normally outweighed by security requirements and handled by connection reuse. Operators should measure critical ingestion jobs after enforcing the setting, especially high-throughput copy tools and legacy appliances. Performance also improves operationally because a clear HTTPS-only baseline removes ambiguity during storage troubleshooting. Benchmark only the workloads that move large volumes or use unusual clients.
Operations
Operators inspect secure transfer required through the portal, Azure CLI, Resource Graph, Azure Policy compliance, and ARM or Bicep templates. Common work includes finding accounts where enableHttpsTrafficOnly is false, confirming whether an exception is justified, changing the setting, and collecting evidence after remediation. Troubleshooting usually starts with storage client errors after enforcement; the fix is often an HTTPS endpoint, updated SDK, regenerated SAS URL, or corrected connection string. Good operations record the old value, the owner, the change ticket, the affected services, and post-change evidence that storage access still works. Runbooks should include example commands so night-shift responders can verify it quickly.
Common mistakes
Assuming private endpoints automatically replace the need for secure transfer when HTTP clients can still be misconfigured.
Turning the setting off for one legacy job and leaving the exception undocumented for months.
Updating production storage without testing connection strings, SAS URLs, copy tools, and backup software that may hard-code HTTP.
Confusing secure transfer required with minimum TLS version, storage encryption at rest, shared key disablement, or firewall rules.
Relying on portal sampling instead of subscription-wide CLI or policy evidence for audit reporting.