Storage account trusted services means letting specific Azure services reach a storage account even when the account firewall blocks most public network traffic. It is often seen as the Allow trusted Microsoft services exception. The setting is not a magic access grant: the calling service still needs the right identity, role, SAS, or service authorization. It is a network exception that helps services such as monitoring, backup, data movement, or security tooling work when strict network rules would otherwise block them.
trusted Microsoft services for storage, AzureServices bypass, storage trusted services exception
Difficulty
fundamentals
CLI mappings
5
Last verified
2026-05-26
Microsoft Learn
Storage account trusted services are Azure service exceptions that can pass a storage firewall when selected network access is restricted. They help specific Microsoft services reach storage for approved scenarios, but they do not replace authentication, authorization, logging, private access review, or least-privilege design.
In Azure architecture, trusted services live inside the storage account network rule set. They interact with public network access, selected virtual networks, IP rules, resource instance rules, private endpoints, and service-specific authorization. The control plane stores the bypass configuration on the storage account, while the data plane evaluates whether a request comes from an allowed trusted service path. Architects use it when an Azure platform service cannot be placed inside the same virtual network but still needs controlled access to logs, metrics, backups, scans, or data processing.
Why it matters
Trusted services matter because storage firewalls often break platform integrations that teams still need. A security team may lock a storage account to selected networks, then discover that diagnostic export, backup, Defender scanning, or a managed data service can no longer reach required data. Turning on every exception without review creates a different problem: a broader network bypass that few people understand. The term forces a precise conversation about which Azure services are trusted, what they can read or write, and which identity authorizes the operation. It helps teams avoid both extremes: open storage accounts and brittle locked-down accounts that silently block operational tooling.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In the storage account Networking blade, trusted Microsoft services or bypass settings appear beside firewall exceptions when selected network access is enforced for production workloads and audits.
Signal 02
In CLI or ARM output, networkRuleSet.bypass shows AzureServices, Logging, Metrics, or None, revealing which platform paths bypass storage firewall rules during security audits and reviews.
Signal 03
In failed integration tickets, the dependency appears after firewall hardening causes 403 errors from monitoring, backup, scanning, or automation workflows during validation and incident review sessions.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Allow a required Azure platform service to reach a locked-down storage account without reopening access to all public clients.
Restore diagnostic export, backup, security scan, or data movement jobs after a firewall hardening change blocks managed service traffic.
Audit which storage accounts rely on trusted service exceptions before tightening public network access or rolling out private endpoints.
Replace vague firewall approvals with evidence showing exact bypass values, dependent services, identities, and compensating controls.
Detect drift where a temporary trusted services exception stayed enabled after a migration, outage, or compliance remediation window.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Port logistics restores protected diagnostics exports
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A port logistics operator locked storage accounts to selected networks after a ransomware assessment. The change accidentally stopped Azure Monitor diagnostic exports that compliance analysts used to investigate crane-control file transfers.
🎯Business/Technical Objectives
Keep storage firewall restrictions in place for application clients.
Restore diagnostic export to the compliance storage account within one release window.
Prove the exception did not grant broad user or vendor access.
Create repeatable evidence for quarterly security testing.
✅Solution Using Storage account trusted services
Cloud engineers inspected networkRuleSet.bypass, defaultAction, private endpoint coverage, and diagnostic settings for the affected accounts. They enabled the trusted services exception only on the compliance account, kept defaultAction set to Deny, and verified that diagnostic export still used the approved destination and managed identity. A CLI job captured the before-and-after values, while storage logs showed that application traffic continued to use private endpoints. Security added an Azure Policy audit that flagged any account with AzureServices bypass but no exception tag and owner.
📈Results & Business Impact
Diagnostic export resumed in 42 minutes instead of the original two-day manual log pull plan.
No public client access was reintroduced; application reads still resolved through private endpoints.
Quarterly firewall evidence preparation dropped from 24 screenshots to one signed JSON export.
Policy identified three stale bypass settings in nonproduction accounts during the first scan.
💡Key Takeaway for Glossary Readers
Trusted services are safest when they are scoped as a documented network exception, not used as a shortcut around storage isolation.
Case study 02
Genomics lab keeps backup tooling alive after firewall hardening
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A university genomics lab stored sequencing exports in Blob Storage and tightened network rules before a grant audit. Backup protection jobs began failing because the managed service path was not covered by subnet rules.
🎯Business/Technical Objectives
Preserve restricted network access for sensitive research data.
Recover automated backup status before the next sequencing batch completed.
Document which managed service depended on the exception.
Reduce manual backup verification work for lab operations.
✅Solution Using Storage account trusted services
The Azure platform team compared storage accounts by tag, redundancy, private endpoint state, and networkRuleSet.bypass value. They confirmed that the backup workflow needed the trusted services path while researchers and pipelines continued to use private endpoints. The team enabled AzureServices bypass only on accounts with active backup policies and attached the backup vault resource IDs to the change record. They tested restore-point creation, reviewed denied network events, and updated the landing-zone module so future research accounts required an explicit backup exception decision.
📈Results & Business Impact
Backup job success returned from 61 percent to 99 percent over the next nightly cycle.
Manual verification time for sequencing data protection fell from six hours weekly to 40 minutes.
Audit reviewers received a precise list of eight accounts requiring the exception.
Two new storage accounts were blocked from production until their backup exception tags were completed.
💡Key Takeaway for Glossary Readers
A locked-down storage account still needs tested platform-service paths for the protection workflows the business depends on.
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
An insurance analytics group inherited hundreds of storage accounts after a merger. Many accounts had trusted services enabled, but nobody could tell whether the setting supported monitoring, data imports, or an old troubleshooting habit.
🎯Business/Technical Objectives
Inventory trusted service bypass across all acquired subscriptions.
Separate required operational exceptions from stale configuration drift.
Lower network-exception findings before the merger compliance review.
Avoid disrupting claims analytics refresh jobs during cleanup.
✅Solution Using Storage account trusted services
Engineers exported bypass, defaultAction, resource group, tags, and diagnostic settings with Azure CLI and joined the output with pipeline ownership data. Accounts with active diagnostic export, Defender, or managed ingestion jobs received named exception records; accounts without evidence were moved to bypass None in staged batches. Each batch watched data pipeline success rate, denied storage requests, and Log Analytics ingestion volume for 72 hours. The final template updated all new analytics storage accounts to require an exception reason before AzureServices could be enabled.
📈Results & Business Impact
Seventy-six stale trusted service exceptions were removed without a missed claims refresh window.
Security review findings fell by 68 percent because each remaining exception had an owner and purpose.
Pipeline incident tickets stayed at normal baseline during the staged cleanup.
Exception reporting moved from spreadsheet guesses to automated subscription-wide CLI evidence.
💡Key Takeaway for Glossary Readers
Trusted services cleanup is a governance win when teams prove which exceptions are real and retire the rest methodically.
Why use Azure CLI for this?
With a decade of Azure work behind me, I use CLI for trusted services because storage network exceptions are easy to misread in the portal. The important evidence is the combination of publicNetworkAccess, defaultAction, bypass, virtual network rules, private endpoints, and role assignments. CLI lets me export those fields for every account, compare production against policy, and prove whether AzureServices, Logging, Metrics, or None is configured. It also supports controlled changes through a pull request or runbook instead of a hurried portal click during a broken backup job. That repeatability keeps security reviews honest and operational fixes traceable. It also makes exception ownership visible during reviews.
CLI use cases
Inventory storage accounts that allow trusted Azure services before a network security review or private endpoint migration.
Capture defaultAction and bypass values as audit evidence after a firewall exception is approved.
Turn on AzureServices bypass for a specific account only after validating the dependent managed service and identity model.
Remove trusted services bypass from accounts where diagnostics, backup, and managed services no longer require it.
Compare firewall rule sets across environments to find production exceptions that were never documented in lower environments.
Before you run CLI
Confirm tenant, subscription, resource group, storage account name, and whether the change is allowed by security policy.
Check publicNetworkAccess, defaultAction, existing bypass values, private endpoints, IP rules, and virtual network rules first.
Identify the exact Azure service, managed identity, or diagnostic workflow that needs the exception before enabling it.
Use output json for evidence, and avoid changing bypass settings in production without a rollback and validation plan.
Remember that network allowance is not authorization; RBAC, SAS, shared keys, and service configuration still control data access.
What output tells you
networkRuleSet.bypass shows whether AzureServices, Logging, Metrics, or None is part of the storage firewall exception model.
networkRuleSet.defaultAction tells you whether unmatched public requests are allowed or denied by the account firewall.
publicNetworkAccess explains whether public endpoint access is enabled, disabled, or governed by a perimeter setting.
ipRules and virtualNetworkRules show the more specific network paths that may already cover the workload without trusted services.
A mismatch between bypass and policy evidence usually means an exception was added manually or inherited from an old deployment template.
Mapped Azure CLI commands
Storage account trusted services CLI commands
direct
az storage account show --name <account-name> --resource-group <resource-group> --query "{publicNetworkAccess:publicNetworkAccess,defaultAction:networkRuleSet.defaultAction,bypass:networkRuleSet.bypass}"
az storage accountdiscoverStorage
az storage account list --query "[].{name:name,resourceGroup:resourceGroup,bypass:networkRuleSet.bypass,defaultAction:networkRuleSet.defaultAction}"
az storage accountdiscoverStorage
az storage account update --name <account-name> --resource-group <resource-group> --bypass AzureServices
az storage accountsecureStorage
az storage account update --name <account-name> --resource-group <resource-group> --bypass None
az storage accountsecureStorage
az storage account network-rule list --account-name <account-name> --resource-group <resource-group>
az storage account network-rulediscoverStorage
Architecture context
Architecturally, trusted services sit at the boundary between locked-down storage and managed Azure platform operations. I treat the setting as an exception path, not a standard integration pattern. When possible, private endpoints, managed identities, resource instance rules, and scoped RBAC are cleaner because they express a narrower trust boundary. Trusted services become useful when the Azure service operates outside a customer virtual network or needs to reach storage through a Microsoft-managed path. A mature design documents exactly which workflows depend on the exception, such as diagnostics, backup, security scanning, or data import. It also verifies that authorization, logging, and policy remain aligned after the firewall exception is enabled.
Security
Security impact is direct because the setting can let selected Azure services bypass storage firewall restrictions. It does not bypass authentication or storage authorization, but it does widen the network path compared with a pure private endpoint or subnet rule design. Security teams should review which trusted service scenarios are enabled, whether shared keys are disabled, which identities can access data, and whether diagnostic logs capture the resulting requests. The risk is not only data exposure; it is also forgotten exception drift. Policy should detect accounts where trusted services are enabled without an approved reason, owner, and compensating access controls.
Cost
Trusted services usually do not create a direct charge, but they influence the cost of secure operations. If the exception keeps diagnostic exports, backup jobs, security scans, or data movement working, those services may generate storage transactions, Log Analytics ingestion, backup usage, or data processing charges. The opposite cost risk is operational: blocking a trusted service can create failed jobs, manual incident effort, missed compliance evidence, and expensive rework. FinOps teams should identify accounts with the exception enabled, the services that use it, and the downstream meters involved. That prevents both hidden platform charges and security exceptions that nobody can justify.
Reliability
Reliability impact is practical but indirect. Trusted services can keep backup, monitoring, export, security, and managed processing workflows working after storage firewalls are tightened. Without it, a production account may appear secure while platform jobs fail quietly, creating missed alerts, incomplete backups, or delayed data movement. At the same time, relying on a broad exception without testing can hide real dependency paths until an outage. Operators should validate each dependent service after changing network rules, monitor failed authorization and denied network events, and document rollback. Reliability improves when exception behavior is known, tested, and tied to named operational workflows. Test jobs should run after every firewall baseline update.
Performance
Runtime performance is not usually improved by trusted services, because the setting changes network allowance rather than storage throughput. Its performance impact shows up in operational workflows: backups complete, diagnostics export, scans finish, and managed services avoid repeated denied-request retries. A misconfigured account can waste time through connection failures, throttled retry loops, or delayed monitoring pipelines. Engineers should measure dependent jobs before and after firewall changes, especially where large log exports or data processing services use the account. For applications, private endpoints and normal data-plane routing still matter more for latency and throughput than trusted service exceptions. Those measurements keep retry behavior from masking configuration problems.
Operations
Operators manage trusted services by inspecting the storage account network rule set, comparing bypass values against policy, and validating the Azure services that depend on the exception. Common operational work includes exporting account firewall posture, tracing denied requests, confirming diagnostic settings, reviewing Defender or backup access, and documenting who approved the bypass. Change tickets should include before-and-after CLI output because portal labels can hide exact values. Operators also need runbooks for removing the exception safely, since disabling it may break monitoring, replication tooling, or protection jobs. Good operations treat the setting as an auditable exception with owners. Expiry dates help prevent permanent undocumented bypasses.
Common mistakes
Assuming trusted services grants data permission, when it only affects network access and still requires authorization.
Leaving AzureServices enabled after a temporary troubleshooting change without an owner, expiry date, or audit note.
Using the exception instead of private endpoints or resource instance rules when a narrower path is available.
Forgetting to test backup, diagnostics, Defender, or data processing jobs after changing storage firewall settings.
Treating every Microsoft service as automatically trusted for every scenario instead of checking the documented supported service list.