MFA coverage
- Actual enforcement, user by user - not the tenant toggle
- Legacy auth and device-code flow still open
- Phishing-resistant methods: who has them, who should
- Weak fallbacks: SMS and voice still allowed
Identity & Access Security Assessment
MFA is on. You are not done.
Today’s attacks steal the session after MFA succeeds. A senior engineer maps how far one stolen token gets in your Entra ID - through Conditional Access, into privileged roles - and hands you the plan that closes the path.
Attack-path assessed, not checkbox-scored
Entra-native: no product to buy
Read-only, no agents, no changes
Standalone, or part of the full M365 assessment
09:14
User signs in through a phishing proxy
Credentials + MFA prompt passed · session token captured
09:16
Token replayed from attacker infrastructure
Conditional Access: no device or location re-check · allowed
09:31
PIM role self-activated with the stolen session
Activation asks for MFA - the token already carries the claim · allowed
09:32
Global Administrator
Tenant takeover · 18 minutes after the click
We map this path in your tenant · then close it, step by step
Why now
You are probably here because…
Identity is where modern attackers operate - they log in, they don’t break in.
The assumption
"We rolled out MFA, so identity is handled"
That is exactly the assumption token theft is built to exploit.
The scare
A risky sign-in from somewhere impossible
Entra flagged it, nobody was sure what it meant, and it kept nagging.
Sprawl
You have lost count of the Global Admins
Years of "temporary" rights, consultants, and service accounts with standing power.
Insurance
The renewal asks about phishing-resistant MFA
And privileged-access management. Two questions most tenants cannot answer well.
Regulation
NIS2 wants access control evidence
Who can touch what, and what proves it - documented, not assumed.
Inheritance
You inherited the tenant and trust nothing
Conditional Access grew by accretion. Nobody knows what the policies actually cover.
80%
of MFA-bypass breaches now run through adversary-in-the-middle session-token theft - attacks that succeed after MFA does.
Microsoft Digital Defense Report 2025
+111%
year-over-year growth in detected token-replay attacks - 147,000 in Microsoft’s telemetry. The stolen token is the new password.
Microsoft Threat Intelligence
The assessment question
How far does one stolen token get in your tenant?
We don’t check whether MFA is on. We map the path from a phished session to your most privileged role - and every step below is a real finding from real tenants.
09:14
A session token is phished
An AiTM proxy relays the real Microsoft login. Credentials pass, MFA passes, and the kit keeps the authenticated session cookie.
Phishing-resistant MFA (FIDO2 / passkeys) cannot be relayed by a proxy
09:16
The token is replayed elsewhere
A valid token from attacker infrastructure. No password guessing, no MFA prompt - most CA policies never look again.
Device compliance in CA · Token Protection · Continuous Access Evaluation
09:31
A privileged role is self-activated
PIM requires "MFA" to activate - satisfied by the claim already on the stolen token. No approval, no re-challenge.
Authentication Context forcing fresh phishing-resistant re-auth at activation
09:32
Global Administrator
Tenant takeover, 18 minutes after the click. Every dashboard stayed green.
No control fires here
A checkbox assessment scores each step “configured”. We test whether the chain holds together - that is what you pay a human for.
Scope
What we actually assess
Six surfaces of Entra ID, specific enough to be checkable. The full M365 assessment touches identity; this goes all the way down.
01/06
Conditional Access
- Who is actually uncovered by each policy
- Excessive exclusions - the "temporary" exemption from 2023
- Scoped-role admins falling outside role-targeted policies
- Protections over-scoped to admin portals only
- Single-condition policies one signal away from failing open
Privileged access & PIM
- Global Admin count, cloud-only status, dedicated accounts
- Standing assignments vs just-in-time activation
- PIM activation: approval, re-challenge, or rubber stamp
- Break-glass accounts: two, cloud-only, alerted on use
AiTM & token defenses
- Phishing-resistant MFA for admins and sensitive apps
- Token Protection and Continuous Access Evaluation
- Authentication Context on PIM and sensitive actions
- Identity Protection risk policies - on, tuned, and acted on
Apps & workload identities
- OAuth consent grants and illicit-consent exposure
- Overprivileged service principals
- App-registration credential hygiene
- Unattended apps with standing Graph permissions
Guests & governance
- Guest and external account inventory and rights
- Dormant accounts with live access
- Joiner-mover-leaver hygiene and privilege creep
- Access reviews: configured, or configured and ignored
The hard part
Conditional Access: who is actually covered?
Fourteen policies that all “work” can still leave your riskiest users uncovered. Exclusions accumulate, scoped roles slip through, and one mis-saved policy can strip MFA from every admin - silently, with no native rollback. We resolve every policy to the people it actually protects.
- Per-policy coverage resolved to actual users - not the policy list
- Exclusion audit: every exemption, with an owner or a removal date
- Scoped-role admins that role-targeted policies silently miss
- One-bad-policy risk: changes that strip MFA from admins fire no alert
All users · MFA policy
112 of 841
Admins · device compliance
4 of 13
Admins · phishing-resistant MFA
8 of 13
Guests · any CA policy
29 of 66
Uncovered = no MFA-equivalent control applies · resolved per user
Crown jewels
Privileged access, inventoried honestly
PIM configured loosely provides far less protection than teams assume - and is often cited as the reason other hardening can wait. We inventory who holds power in your tenant, how it activates, and what a stolen session could do with it.
- Every privileged role, resolved to humans and workloads
- Standing vs just-in-time, with the migration plan
- PIM activation settings tested against token replay
- Break-glass design that survives a lockout and an audit
Global Admins
14 accounts hold the role. Microsoft’s guidance: fewer than five, cloud-only, dedicated.
Sprawl
Standing access
11 permanent assignments. Privileged roles held around the clock - no activation, no window.
Standing
PIM activation
MFA-only, no approval. A stolen token carries the MFA claim - activation is a rubber stamp.
Weak
Break-glass
One account, MFA-enrolled. Should be two, cloud-only, excluded by design, alerted on every use.
Partial
Role reviews
Never run. No scheduled review has ever pruned a privileged assignment.
Missing
Redacted composite · the five most common findings
The modern layer
Does your configuration stop the attacks that beat MFA?
These six controls decide whether the token-theft path stays open. Each one is checked in the assessment - with the licensing you need, and mostly already have.
Phishing-resistant MFA
Entra ID P1FIDO2 keys, passkeys, Windows Hello - methods a proxy cannot relay. The single strongest AiTM defense.
Do your admins and finance have it? Does anything enforce it?
Token Protection
In Conditional AccessCryptographically binds sign-in tokens to the device they were issued on. A stolen token stops working elsewhere.
Scoped to what it can protect, or not deployed at all?
Continuous Access Evaluation
Default-capableRevokes sessions in near-real-time on risk events and location changes, instead of waiting for token expiry.
Enabled - and are the revocation events actually monitored?
Authentication Context
Entra ID P1Forces a fresh, phishing-resistant re-challenge at sensitive moments: PIM activation, security-setting changes.
Or does your PIM accept the MFA claim already on the token?
Identity Protection
Entra ID P2Risk-based detection of impossible travel, anonymised IPs, token anomalies - wired into Conditional Access as enforcement.
On and enforcing, or generating reports nobody reads?
Legacy auth & device-code blocks
FreeThe old protocols that never trigger MFA, and the device-code flow AiTM kits abuse. Blocking both costs nothing.
Blocked tenant-wide, or open through three exceptions?
Before you buy anything
You probably don’t need an identity security product.
The ITDR market wants to sell you a platform. But many tenants already pay for Entra ID P2 and never turn on Identity Protection or PIM - so AiTM runs undetected until the attacker acts. The assessment is partly this question: you already own the controls that would stop this. Are they on, and are they configured to mean it?
Where licensing genuinely matters
- Conditional Access needs P1 - on Business Basic, we say so and scope around it.
- Identity Protection and PIM need P2; the report flags every fix that needs a step up, with the cheaper alternative alongside.
- If your licensing genuinely cannot close a gap, the report says that too - with what it costs to fix versus what it risks.
You likely ownEntra ID P1 or P2
Sitting unusedIdentity Protection · PIM
Third-party ITDR€5-15 / user / month
Our incentiveWe sell the fix, not a license
Method & safety
Safe enough to run on a Tuesday morning
Same ground rules as every Falconer assessment. Nothing about your sign-in experience changes while we work.
Read-only, always
No settings changed, no agents installed, no user impact. Sign-ins continue untouched.
Access you control
Scoped, delegated read access via GDAP - granted by you, revocable by you the day we finish.
Native tooling for coverage
Identity Secure Score, Entra recommendations, CISA SCuBA baselines, and enumeration tooling that resolves policies to people.
Humans for judgment
A senior engineer chains the findings into attack paths and puts them in fix order. The tooling is the start, not the deliverable.
Days, not weeks
Collection is hours, analysis is days. Findings arrive while they are still true.
Your data stays yours
Evidence handled under GDPR, stored in the EU, deleted on the schedule we agree.
The deliverable
The three-reader report, plus three named artifacts
Same format as our full M365 assessment: an executive summary for the board, remediation-ready findings for IT, and compliance mapping (NIS2, ISO 27001, GDPR) for the auditor. Identity adds three artifacts of its own.
CA coverage map
Every policy resolved to the users it actually protects - and the ones it silently misses. The sample above is an excerpt.
Privileged-access inventory
Global Admins, standing assignments, PIM posture, and break-glass status, with the migration plan to just-in-time.
MFA gap analysis
Registered vs enforced, user by user, plus phishing-resistant adoption - the two numbers your insurer now asks for.
Includes a 1:1 readout call.
We walk the attack paths with you, agree the fix order, and answer the “how bad is this really” questions in plain language.
How this fits
Email in, SOC out
Identity is the hub of the assessment set - and honesty about its edges is part of the assessment.
Email in
Phishing is the delivery vector
The riskiest sign-in follows a phishing hit, which is why email detections should feed Conditional Access. Assessed on the email page. Explore Email Security.
This page
Cloud identity in Entra ID
MFA, Conditional Access, privileged access, tokens, apps, and governance. On-prem Active Directory chains - DCSync, Kerberos abuse - sit outside Entra’s visibility and this scope; we refer AD assessments to trusted partners.
SOC out
Detection is behavioural, not preventive
No configuration stops everything: stolen-token detection is a monitoring problem. Risky sign-ins and token anomalies are first-class SOC signals - that is MDR on Sentinel. Explore MDR.
Identity is one surface of four.
This assessment runs standalone - fixed fee, sized by tenant - or as the identity module of the full Microsoft 365 Security Assessment, which adds email, collaboration, and posture in the same three-reader report.
FAQ
The questions identity buyers ask
We already enforce MFA - isn’t that enough?
It is necessary, and it is no longer sufficient. Modern phishing kits proxy the real login page, let MFA succeed, and steal the session token that comes out the other side. Microsoft attributes 80% of MFA-bypass breaches to exactly this. The question the assessment answers is whether your configuration stops the attacks that beat MFA.
What is AiTM / token theft, in plain language?
An attacker sits between your user and Microsoft with a look-alike login page that relays everything in real time. The user signs in successfully - password, MFA prompt, all of it - and the attacker keeps the resulting session cookie. From then on they are the user, no password or MFA prompt required, until that token is revoked or expires.
Our Conditional Access "works" - what could be wrong with it?
Coverage, usually. Policies accumulate exclusions, role-targeted policies miss admins with scoped assignments, and protections get scoped to admin portals while Graph and CLI stay open. We resolve every policy to the actual humans it covers - that map is usually the most surprising page in the report.
How many Global Admins is too many, and what is PIM?
Microsoft’s own guidance says fewer than five, cloud-only, in dedicated accounts. PIM (Privileged Identity Management) replaces standing admin rights with just-in-time activation - but configured with MFA-only activation and no approval, it barely slows a stolen token down. We assess both the sprawl and the activation settings.
Do we need passkeys / phishing-resistant MFA?
For your admins and your most-targeted users: yes, and increasingly your insurer agrees. FIDO2 and passkeys cannot be relayed by a phishing proxy, which kills the AiTM path at step one. We assess adoption and enforcement, and recommend the rollout order - deployment itself we scope separately.
Do you cover on-prem Active Directory too?
No - honestly, and on purpose. This assessment covers cloud identity in Entra ID. On-prem AD attack chains (DCSync, Golden Ticket, Kerberos abuse) need different tooling and visibility, and we refer those engagements to trusted partners rather than pretending one assessment covers both.
Is it safe? Will users notice anything?
Nothing changes. The assessment is read-only through delegated access you grant and can revoke - no agents, no configuration changes, no sign-in interruptions.
What exactly do we get?
The three-reader report - executive summary, remediation-ready technical findings, compliance mapping - plus three identity artifacts: the CA coverage map, the privileged-access inventory, and the MFA gap analysis. And a 1:1 readout call to walk the attack paths.
What licensing do your recommendations assume?
Whatever you actually have. Conditional Access needs Entra ID P1; Identity Protection and PIM need P2. The report grounds every recommendation in your current licensing, flags the few fixes that genuinely need a step up, and gives the cheaper alternative alongside.
Do you fix the findings, or just report them?
Your choice. Every finding ships with the fix - portal steps or PowerShell - so your team can remediate in-house. If you want help, we offer scoped remediation, and for the detection side (stolen tokens are caught by monitoring, not configuration) the natural next step is MDR on Sentinel.