Eight weeks ago, on March 22, Okta and Microsoft each confirmed that the extortion group tracked as LAPSUS$ had been inside their environments. Okta's exposure ran through a third-party support engineer's laptop, compromised back in January; Microsoft's ran through a single account that walked out with partial source for Bing, Bing Maps, and Cortana. Neither was a zero-day. Both were a credential, a session, or a support process nobody downstream questioned. We've spent the eight weeks since running a Conditional Access hardening pass across five client tenants — a state agency, a regional bank, a 6,000-seat manufacturer, and two smaller estates — because that is the actual lesson out of March, not "buy another security product."
This note is what that pass looks like on the ground: which policies we ship, in what order, and where clients still manage to lock out their own CEO despite our best efforts. Conditional Access itself isn't new in May 2022 — four of these five tenants had a "require MFA for all users" policy running untouched since 2019 or 2020. What changed is the shift from "MFA exists" to "MFA plus a device signal plus an authentication method, tuned per persona, proved in report-only before it ever blocks a real sign-in" — racing its own deadline: Microsoft's October 1 cutoff for Basic Authentication in Exchange Online, a little over four months out.
A policy set that survives contact with the CEO's iPad
Every one of these five tenants walked in with the same starting position: one tenant-wide "require MFA" policy, applied to all users, written years ago and never revisited. That policy isn't wrong. It fails in both directions at once — too loose for a Global Administrator signing in from an unmanaged laptop at 2 a.m., too brittle for a traveling CFO who trips a country-block rule nobody told her existed.
We stopped writing one policy per tenant and started writing one policy set per persona:
| Persona | Scope | Grant controls | Report-only dwell |
|---|---|---|---|
| Standard workforce | All cloud apps | MFA + (compliant device or approved app) | 2 weeks |
| Privileged roles | All apps + Azure mgmt | MFA + compliant device + block legacy auth | 2 weeks, no early graduation |
| Service accounts | Scoped per app | Block interactive sign-in; alert instead | Alert-only |
| Guests / B2B | All cloud apps | MFA always; no named-location exception | 2 weeks |
| VIP / executive | All cloud apps | MFA + named locations + manual exception path | 2 weeks + dry run before travel |
Two choices make this hold up where a blanket policy can't. Named locations — corporate egress ranges, VPN concentrator IPs, an executive's pre-booked hotel block — reduce friction; they don't replace the gate. A compliant device from a named location skips a repeat MFA prompt; a non-compliant one gets challenged regardless of IP, since IP is the cheapest signal in the stack to fake. And the VIP exception is rehearsed before the trip, not improvised from a hotel business center at midnight. One bank on this list hit the Frankfurt scenario eighteen months before we arrived — a returning executive hard-blocked with no path around a country rule except an emergency admin unlock at 2 a.m. The fix was never removing the block; it was a pre-registered location tied to the travel calendar and an exception workflow that doesn't require a Global Admin to be awake.
Legacy authentication has a death date: October 1
Four of the five tenants still had measurable Basic Authentication traffic in their sign-in logs the week we opened them — the real headline of this program, more than any single Conditional Access policy. On October 1, Microsoft disables Basic Authentication in Exchange Online — Outlook, Exchange ActiveSync, Exchange Web Services, POP, IMAP, remote PowerShell — for any tenant that hasn't already turned it off, a date it announced back in September 2021 via admin-center warnings almost nobody reads.
Finding what still depends on it is the easy part. Azure AD's sign-in logs carry a client-app filter that separates modern authentication from the legacy bucket — the same "Other clients" and "Exchange ActiveSync clients" grouping a Conditional Access "block legacy authentication" policy targets. Filter thirty days of that bucket and you get the real inventory, not the one in the CMDB. What we found matched what we always find: a scan-to-email copier fleet still authenticating SMTP with a password saved in 2016, a CRM connector polling a shared sales inbox over IMAP, two service accounts running an on-prem script against Exchange Online with no owner anyone could name, and one finance user still on an old Outlook build because her machine never took the Microsoft 365 Apps update.
Our kill sequence is boring by design: inventory from the sign-in logs and Exchange Online's per-protocol authentication policies, remediate each tail item (a relay connector for the copiers, an OAuth registration for the CRM tool, a certificate-based app registration replacing the stored password for the service accounts, an app upgrade for the Outlook holdout), then block per protocol against a pilot group before touching the tenant default:
New-AuthenticationPolicy -Name "Block-Legacy-Auth-Pilot"
Set-User -Identity jane.doe@client.com -AuthenticationPolicy "Block-Legacy-Auth-Pilot"
Get-User -ResultSize Unlimited -Filter {AuthenticationPolicy -eq $null} |
Select-Object DisplayName, UserPrincipalName
Our Conditional Access block is broader than Microsoft's own date and protocol list — it stops the entire legacy-client bucket tenant-wide the moment it enforces, whatever protocol Microsoft has or hasn't gotten to. We'd rather flip that switch ourselves in June or July, on our own schedule with our own rollback plan, than have Microsoft flip it for us on October 1 while we're triaging whatever else that week brings.
Report-only isn't a formality, it's the whole point
Every new policy in this program spends a minimum of two weeks in report-only before it enforces anything, no exceptions, including the ones we're sure about. Every sign-in event already carries a Conditional Access tab showing each applicable policy's result as success, failure, or report-only, and the Conditional Access insights and reporting workbook under Monitoring rolls that up by policy, user, and app — no hand-built spreadsheet required.
Discipline means two things. A hard minimum dwell time, so a policy survives an end-of-month close, a Monday-morning login surge, and one person working from an airport lounge before it goes live. And we read the workbook before flipping anything, not after the helpdesk phone starts ringing. The number we watch: how many report-only failures hit a persona group the policy was never meant to touch. A "require compliant device" policy aimed at managed Windows laptops that's throwing failures against forty guest accounts isn't a guest problem — it's a scoping bug caught for free.
We found the opposite failure as often: policies written in report-only back in 2020 or 2021, for a project that lost momentum, still sitting there, dutifully logging failures nobody has looked at since the kickoff meeting. One state agency had eleven Conditional Access policies in report-only when we opened their tenant. Three were superseded by policies that later went live. Two had scoping broad enough to have blocked half the directory if switched on. The rest were fine and forgotten. Report-only is not a queue you empty by ignoring it:
SigninLogs
| where TimeGenerated > ago(30d)
| where ConditionalAccessStatus == "reportOnlyFailure"
| summarize FailureCount = count() by AppDisplayName, tostring(ConditionalAccessPolicies)
| order by FailureCount desc
Break-glass accounts built to survive 2 a.m., not an audit
Every tenant in this program gets two break-glass accounts: cloud-only, never synced from on-prem AD, so a domain controller compromise or an Azure AD Connect outage can't take them down too. Both are excluded from every Conditional Access policy by object ID, not group membership — membership is exactly the kind of thing that quietly changes during a reorg. Neither has MFA registered, deliberately: the reason these accounts exist is to work when the normal authentication path is unavailable, compromised, or the incident's actual subject.
The part everyone skips is testing. We ask every client to sign in with a break-glass account once a quarter, from somewhere that isn't the office, and confirm two things: the password still works, and someone gets paged. Both fail more often than seems reasonable. At one state agency, the password had been rotated during a compliance sweep eight months earlier and never resealed anywhere retrievable — it existed, taped inside a desk drawer reassigned twice since. At a different client, a later "require MFA for all users" rewrite applied a little too literally, silently swallowing the two accounts meant to be exempt from it. Neither gap shows up until the night someone needs the account — the worst possible night to discover it.
A sign-in to a break-glass account is itself a detection rule, not an afterthought — an alert that pages security on-call the moment either account authenticates outside a declared test window. If nobody scheduled a drill and one of these two accounts signed in, that is the incident.
Device compliance is the signal worth trusting
Named locations and IP ranges cut prompt fatigue but make a poor sole gate — a VPN client costs nothing and defeats them completely. Device compliance is the signal we're willing to lean on: require the device marked compliant through Intune, or a hybrid Azure AD joined device for corporate Windows, paired with an approved client app and app protection policy for personal phones running Outlook mobile, so a BYOD user gets mail without enrolling the entire handset.
The trap is sequencing. Device compliance as a grant control is only as trustworthy as your Intune coverage, and none of these five tenants were anywhere near complete when we started. One manufacturer had a third of its laptop fleet more than sixty days since last check-in, a compliance policy requiring BitLocker that silently failed on machines with bad TPM firmware, and no dashboard surfacing any of it. Turning on "require compliant device" against that population the same week we found the gap would have locked out real machine operators on a factory floor, not attackers — exactly why this policy sits in report-only longer than any other in the set, to surface the compliance gap before it becomes a production outage instead of a security win.
Once that gap closes, this control earns its keep against the playbook Okta and Microsoft each described in March: a stolen password, or a replayed session token, doesn't get an attacker past "require compliant device," because their attack machine was never enrolled in Intune and never will be — harder to fake than an IP address or a single MFA approval tap.
If you're facing this
If your last Conditional Access review predates your last MFA-fatigue headline, or nobody in the building can tell you today whether the break-glass password still works, that is the actual starting point — not a new license purchase. We help Microsoft-centric identity estates build the persona-based policy set, prove it in report-only, and retire legacy authentication on a schedule they control instead of one Microsoft sets for them. Bring your tenant's current sign-in logs and we'll tell you what they already show.