Entra ID
The most productive target in any Azure estate.
- Directory role assignments, standing and eligible
- App registrations, secrets and certificate expiry
- Delegated and application consent
- Guest accounts and external collaboration
Azure fails in its own way, and a review written for AWS will miss most of it. The interesting findings are in Entra ID: application registrations with credentials that never expire, consent granted to applications nobody can now name, directory roles handed out for a single task three years ago, and the standing path from a compromised identity to the subscriptions underneath.
In Azure the directory is not a component of the environment, it is the environment. Entra ID governs the subscriptions, the data services, Microsoft 365 and usually the staff laptops as well, which means a single over-privileged application registration can be worth more to an attacker than any server you own.
So the review starts there and works down: who holds directory roles, which applications hold credentials and what those credentials can do, what consent has been granted and by whom, and whether conditional access actually applies to the accounts that matter or has quietly been excluded for the ones that complained.
Structured on the CIS Microsoft Azure Foundations Benchmark, with the directory work taken further than the benchmark asks.
The most productive target in any Azure estate.
Tested against real accounts rather than read from a policy blade.
Who can do what, and where that was inherited from.
What is reachable and what is lying in the open.
What a compromised workload can reach.
Whether you would know afterwards.
A Reader role on the subscriptions and a directory reader role is enough to start.
Before any resource is looked at.
Against the benchmark, so there is a number.
From each identity to what it can reach.
Fixes ordered by how many paths they close, and a free retest.
Two documents and a conversation. Written so the person who signs the invoice and the person who writes the fix can both use them.
The work follows CIS Microsoft Azure Foundations Benchmark, Microsoft Cloud Security Benchmark, MITRE ATT&CK for Cloud and NIST SP 800-115, so the coverage can be checked rather than taken on trust, and the report maps to what your auditor or your enterprise customer already recognises.
This page is one part of our cloud security service. Where a finding needs a different kind of engagement to answer properly, we say so in the report rather than selling you the test we happen to be running.
Reader on the subscriptions in scope and Global Reader in Entra ID. That is enough for the whole review. For attack-path work we also ask for a deliberately low-privileged account to start from.
The directory work does, because it is the same directory - roles, applications, consent and conditional access all apply to both. A full Microsoft 365 configuration review of Exchange, SharePoint and Teams settings is a separate piece of work, and we will say so during scoping rather than quietly leaving it out.
For penetration testing of your own Azure resources, Microsoft publishes a unified penetration testing rules of engagement that permits it without prior approval, with exclusions. We check the current version during scoping and keep the work inside it.
It is a great deal better than standing assignments, and it is not the whole answer. What we look at is whether the eligible assignments are themselves too broad, whether approval is actually required, and which accounts are excluded from it - the exclusions are usually the finding.
No. This measures the whole estate against a benchmark. Cloud penetration testing starts from one foothold and shows what can be reached with it.
Tell us what you need tested. Our team will reply with a clear scope and quote.
An assistant, not a person, so check anything important with us. Please do not type passwords or card numbers here. Messages are kept so we can answer you better.