They often treat encryption as the finish line instead of the baseline. Encryption protects data at rest and in transit, but it does not stop authorised users, service principals, or connected apps from moving data where policy does not allow it. DLP and monitoring have to cover those paths.
Encryption is baseline, not the control boundary
In Azure, encryption mainly protects confidentiality if a disk, snapshot, backup, or network path is exposed. It does not define who is allowed to use the data once they can reach it, nor does it stop a legitimate identity from copying data into an approved but unintended location. That is why encryption has to be treated as a baseline control, not the final answer.
The common mistake is assuming that because data is encrypted, policy is automatically enforced. In practice, the larger question is whether access paths, application permissions, and export channels are constrained so that authorised movement is still governed.
Where the real exposure sits in Azure
Azure data paths often extend well beyond the storage service itself. A user, service principal, managed identity, application integration, or automation job may have perfectly valid access to read encrypted data and then write it to another resource, tenant, region, or SaaS endpoint. When that happens, encryption has not failed, the policy boundary has.
This is why teams need to think in terms of data flow control, not just data protection at rest. A secured storage account does little if the connected application can enumerate records, pull them through an API, and place them somewhere monitoring does not watch.
For cloud identity and app access, the Cloud Workload Identity Guide is useful because it shows how Azure managed identities, service principals, and federated access become the practical control plane for workload movement. The hardening implications are also clear in the Active Directory and Entra ID Hardening Guide, especially where privileged groups, delegation, and tiered administration shape who can reach what.
Why encryption fails as a governance story
Encryption is often deployed as if it were a compliance milestone, but governance problems usually appear elsewhere: overprivileged identities, weak app consent controls, broad Key Vault access, or unmanaged service principals. If a control can only answer “is the data encrypted?”, it cannot answer “can the wrong actor move the data somewhere else?”
That distinction matters in Azure because the platform is built around identities, roles, and resource relationships. A role assignment can expose secrets, a token can authorize export, and an app registration can become a quiet conduit for data egress even when the underlying storage is encrypted. The right control set has to include access reviews, least privilege, logging, and alerting on unusual data movement.
Historical compromise patterns reinforce this point. The Microsoft verified publisher OAuth phishing 2022 example shows how legitimate app consent can be abused for mailbox access, while Microsoft Storm-0558 key breach 2023 shows that token forgery and signing trust can bypass assumptions that encryption alone would never address.
Risk and Threat Considerations
Encryption can create a false sense of containment when the actual risk is authorised exfiltration through trusted identities, applications, or cloud permissions. If teams do not monitor post-decryption usage and export paths, an attacker or insider can move data without ever breaking the encryption layer.
Failure mechanism: A valid identity, token, or app permission is used to read encrypted data and copy it into a destination that policy does not meaningfully govern, such as another workload, tenant, or external service.
Impact: Confidential data leaves the intended control boundary while encryption remains technically intact, which makes detection slower and accountability harder.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack surface, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Azure data movement needs monitoring and review of use after decryption. |
| AC-6 — Least Privilege | Overprivileged users and apps can move data beyond intended policy. | |
| Recommendation — Review audit events for reads, exports, and relays of sensitive data. Restrict read and export permissions to the minimum needed. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control must govern who can reach and move encrypted data. |
| Recommendation — Define and enforce access rules for data and export paths. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Service principals and managed identities can move data when overprivileged. |
| NHI-07 — Long-Lived Secrets | Persistent app secrets and tokens often enable silent data movement. | |
| NHI-02 — Secret Leakage | Compromised tokens or keys can expose encrypted data paths. | |
| Recommendation — Reduce permissions on Azure service identities that can export data. Replace long-lived Azure app secrets with short-lived credentials. Protect and rotate secrets that unlock cloud data access. | ||
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Apps can move data incorrectly when object-level access is weak. |
| API5 — Broken Function Level Authorization | Export functions can bypass intended policy even when data is encrypted. | |
| Recommendation — Enforce object-level authorization on APIs that expose data. Restrict sensitive export and admin functions to approved roles. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Cloud identity controls govern who can move encrypted Azure data. |
| LOG — Logging and Monitoring | Monitoring is required to detect post-decryption data movement. | |
| Recommendation — Apply cloud IAM controls to identities that can read or export data. Monitor access and exfiltration signals across Azure data paths. | ||
Practitioner Guidance
What to verify: Confirm that every Azure data path has an owner, an access policy, and logging that can show who read, exported, or relayed the data. If you cannot trace those events, encryption is being overcounted as a control.
Decision rule: If an identity can decrypt, query, or export production data, treat that identity as a high-value access path and apply tighter authorization, monitoring, and review than you would for storage encryption alone.
What good looks like: Sensitive data can be encrypted everywhere, yet still only move through tightly scoped identities and monitored integrations. That is the right operating model: encryption plus enforceable usage controls, not encryption in isolation.
Practitioner takeaway: The most reliable Azure programs assume encryption protects exposure, while identity, app permissions, and DLP determine whether the data can be moved responsibly after it is decrypted.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org