Seven Azure Security Gaps Organizations Commonly Miss
The findings that matter in a Microsoft security review are rarely clever. They are the same handful of gaps, in tenants of every size, and almost all of them are ownership problems wearing a technical disguise.
Security reviews of Microsoft environments produce long reports. Strip out the noise and the same seven findings account for most of the real risk, in tenants with fifty users and tenants with fifty thousand.
None of them require an attacker to be sophisticated. Most of them are the default state of a tenant that was set up quickly and then grew.
1. Privileged roles that never expire
Somebody is a permanent Global Administrator. Usually several somebodies: the person who set up the tenant, the managed service provider who migrated the mailboxes, a consultant from two years ago.
Standing privilege is the finding that matters most, because it converts any successful phishing of one of those accounts into full control of the tenant. Privileged Identity Management exists to make elevated roles time-bound and approved — a person becomes an administrator for two hours, with a reason logged, and stops being one afterwards.
The related miss is the break-glass account. Every tenant needs one, excluded from Conditional Access so it works when everything else is broken. Far fewer tenants alert when it signs in. An emergency account that can be used silently is not an emergency account. It is a backdoor with a friendly name.
2. Conditional Access with holes in it
Most tenants have Conditional Access. Most of those policies do not cover everything they are assumed to cover.
Three gaps recur. Legacy authentication — protocols that cannot do MFA — is still allowed, so a password alone works for anything old enough to use them. Exclusion groups created for a rollout have quietly become permanent and grown to include people who simply complained. And workload identities — service principals and managed identities — sit outside the user policies entirely, which is fine until one of them holds a secret that leaks.
The policy set is not the control. The coverage is. Report on what is not covered, not on what is.
3. Applications with more permission than anyone intended
Two versions of this appear together.
Users can consent to third-party applications. The default in many tenants still lets any user grant an external app access to their mail, files and profile, which is precisely the mechanism of consent phishing: no password stolen, just a permission granted.
Meanwhile the organisation’s own app registrations accumulate application permissions — the kind that act as the application against every user’s data, rather than on behalf of the signed-in person. They were granted during development because delegated permissions were harder to make work. Nobody went back.
Turn user consent into an admin workflow, and review every application permission against the question: does this need to read everyone’s data, or just the current user’s?
4. Secrets where identities should be
Connection strings in application settings. A storage account key in a pipeline variable. A service principal client secret shared between four systems, set to the maximum expiry, with nobody sure where it is used.
Azure has spent years making this unnecessary. Managed identities give a workload an identity of its own, with no secret to store, rotate or leak. Key Vault holds whatever genuinely must be a secret, with access controlled by identity and every retrieval logged.
The gap is not that teams do not know this. It is that the secret-based approach worked on day one and the identity-based one required a design decision. Two years later the secrets are everywhere and the inventory of where is incomplete — which is the actual finding.
5. Storage that is more public than anyone realised
Storage accounts are where data lives, and their defaults were built for convenience.
Anonymous blob access allowed at the account level, so a single misconfigured container exposes its contents to the internet. Shared key authentication enabled, so anyone with the key bypasses every identity control. Public network access permitted, with no private endpoint, so the storage account has a routable address and the only thing between it and the world is a key.
Each setting has a safe value. Disable anonymous access, disable shared key, require private endpoints — and enforce all three with Azure Policy at the management group, so the next storage account is born compliant rather than discovered later.
6. Logs that go nowhere
This is the gap that turns an incident from a bad afternoon into a bad quarter.
Diagnostic settings are not configured on most resources, so the platform is not recording what they did. Entra ID sign-in and audit logs are retained for thirty days by default, and an investigation almost always needs to look further back than that. Defender for Cloud plans are enabled for some resource types and not others. Where alerts do fire, they arrive in a mailbox nobody is assigned to read.
The remedy is unglamorous: route Entra ID and Azure activity logs to a Log Analytics workspace with meaningful retention, turn on Defender plans by policy rather than by hand, and — this is the part organisations skip — give every alert category a named owner and a response runbook. A detection nobody acts on is a log line.
7. Access that was granted and never taken back
Guest accounts invited for a project three years ago, still active. Group memberships that reflect where people used to work. Subscription Owner assigned to an individual rather than a group, then that individual left.
Nothing here is a misconfiguration. Every one of these was correct when it was done. The gap is the absence of a lifecycle: access reviews that force somebody to re-confirm that the guest still needs access, entitlement management that gives access an expiry date by default, and a routine that removes what was never re-confirmed.
Access with no expiry is a liability that compounds quietly.
The pattern underneath
Read the seven again and notice what they have in common. Not one is a missing product. Every capability mentioned — PIM, Conditional Access, admin consent, managed identities, Key Vault, Azure Policy, Defender, Sentinel, access reviews — is already in the Microsoft platform most of these organisations are paying for.
What is missing is ownership. Somebody has to decide that standing privilege is not acceptable, that coverage is what gets reported, that every alert has a name next to it, that access expires by default. Those are decisions, and they can be made in an afternoon.
A read-only review of the tenant surfaces all seven in days, with no change made to anything. Which of them are worth fixing first is then a short conversation — and considerably shorter than the one that follows an incident.