Azure security assessment
Entra ID is the perimeter. Most Azure findings start in identity and end in a subscription nobody remembered was still there.
The context
What actually breaks on Azure
On Azure, identity is the perimeter, and almost everything we find starts in Entra ID. Subscriptions, resource groups and network controls matter, but the fastest route into an Azure estate is usually a credential or a consent grant rather than an exposed port.
App registrations are the recurring problem. They accumulate. Someone creates one for an integration, grants it directory-wide Graph permissions because the documentation said to, adds a client secret with a two-year expiry, and leaves. Two years later the secret is still valid, still in a CI variable, and nobody can say what the app is for.
The second pattern is Conditional Access with gaps. The policy set looks comprehensive until you enumerate what it does not cover: legacy authentication protocols, break-glass accounts, service principals, or a specific application excluded during a migration and never re-included.
Assessed surfaces
Everything we look at on Azure.
- 01Entra ID roles, app registrations, service principals & consent grants
- 02Conditional Access policy gaps and MFA bypass paths
- 03Subscription & management group RBAC inheritance
- 04Storage account access, SAS token scope & lifetime
- 05Key Vault access policies and RBAC, secret rotation
- 06NSGs, Azure Firewall, Private Link & public endpoint exposure
- 07AKS RBAC, managed identity assignment, Defender coverage
Questions
Azure FAQ
Reader at the subscription or management group scope, plus Security Reader and the Global Reader role in Entra ID. Read-only throughout. Directory-level read is important because most findings live in identity rather than in the resource plane.
Yes, and specifically the exclusions. Policy sets are usually well designed in the abstract and undermined by the exceptions added under delivery pressure. We enumerate what each policy does not cover and test whether those gaps are reachable.
Where it is in scope we look at it, because the identity plane is shared and a compromise in one reaches the other. Sharing settings, external collaboration defaults and mail flow rules are common sources of data exposure that a pure infrastructure review would miss.
Other platforms we assess
A CI role assumable from an unrestricted GitHub OIDC condition, chaining into production admin.
AWS assessmentA downloadable service account key with project Editor, committed to a repo two years ago.
Google Cloud assessmentA read-write API token in a build environment variable, with no expiry and no rotation record.
DigitalOcean assessmentFind out what is reachable in your Azure estate.
Read-only access, one to two weeks, fixed price. You get attack paths with proof, not a posture score.
No sales sequence. A scoping call and a written proposal cost nothing.