Azure security assessment

Common findings (examples)

• An identity with more privilege than its job needs, or a path from a low-privilege role to administrator.
• Storage buckets or databases reachable from the internet without a good reason.
• Security groups or firewall rules that leave management ports open to the world.
• Long-lived access keys or secrets in instance metadata, pipelines or code repositories.
• Logging turned off, or alerts that would not fire on the paths an attacker actually uses.

What we need from you

• List of in-scope subscriptions (and organisation or management structure if used).
• Read-only access for the review role, created by you and revoked when we finish.
• A named contact for production change windows and out-of-scope services.
• Architecture notes or diagrams if you have them (helpful, not required).

Typical timeline

Duration depends on how many subscriptions and services are in scope. A single subscription with a focused service set is often a short engagement; a multi-subscription organisation with containers, data stores and custom identity federation takes longer. Dates are agreed after the scope call.

Standards and method

Coverage is guided by the Microsoft cloud security benchmark and CIS-aligned Azure controls, then validated by a tester. Assessment practices follow NIST SP 800-115.

Depth by service family

• Identity. Directory roles that control Azure, privileged identity settings, managed identities, service principals and federation into subscriptions.
• Network. Virtual networks, NSGs, application gateways, firewalls you run in Azure, private endpoints and public exposure.
• Compute. Virtual machines, scale sets, AKS, container apps, App Service and Functions — including run-command and serial-console risk.
• Data. Storage accounts, SQL and other databases, backups and snapshot access.
• Keys. Key Vault RBAC and access policies, certificates and secrets in app settings or pipelines.
• Detection. Activity logs, diagnostic settings, Cloud security recommendations that matter, and SIEM coverage gaps for Azure activity.

What stays out of scope by default

• Full Microsoft 365 tenant review (see the Microsoft 365 security assessment).
• Changing role assignments or network rules (review is read-only).
• Subscriptions or management groups you did not name.
• Denial-of-service against production.

Multi-subscription estates

Landing zones with many subscriptions are normal. We follow identity and network trust across the management groups you name, so a jump subscription that can reach production Key Vault is visible as one path. Per-subscription noise is filtered unless it changes what an attacker could reach.

Scope and rules

• Scope call. Subscriptions, services in use, production limits and any services that must not be touched.
• Read-only access. You grant a least-privilege review role. We confirm it before testing starts.
• Configuration review. Identity, network, compute, data, keys and logging against the Azure security benchmark and common CIS control language.
• Attack-path analysis. From realistic starting identities (a developer role, a compromised workload identity, an over-permissive service account), we map what could be reached.
• Controlled validation. High-risk paths are checked safely where agreed. Destructive actions stay out of scope.
• Report and retest. Findings with evidence, a walkthrough and a retest of fixes that are ready within 6 months of the original test (up to 10 issues).