Another August, Another Entra ID Emergency
Yesterday, on August 20, Microsoft disclosed CVE-2026-69836: unauthenticated remote code execution in Entra ID's backend, via deserialization of untrusted data (CWE-502). CVSS 10.0. No login, no user interaction, low complexity. Microsoft's bulletin first said "Exploited: Yes"; a day later it said "No". Take whichever answer you prefer - everything that follows is true either way.
The reassurance arrived on schedule: fully mitigated server-side, no customer action required. All true. None of it answers the question that matters: what were the attackers there for?
Not Microsoft. Nothing in an IdP's backend is worth ransoming - nobody breaks into a mint for the furniture. The one thing worth taking is the power to vouch for everyone else: signing authority that becomes valid SAML responses and tokens for any user, at any organization that trusts it.
To log in to your organization, they broke into Microsoft. Attackers log in rather than break in, as my colleague Gilad puts it - and the surest way to log in anywhere is to break into the one place that mints the logins. Microsoft was not the target. Microsoft was the road.
Two Bugs, One Destination
Rewind a year to CVE-2025-55241: another perfect 10.0, and a bug that could not look less like this one. Undocumented actor tokens, minted for Microsoft's internal service-to-service traffic, were accepted by the legacy Azure AD Graph API with no check on which tenant they came from.
The result: silent, total takeover of your tenant. Anyone with a free test tenant could request a token, present it to yours, and become your Global Administrator. No MFA. No Conditional Access. No audit log on your side. Dirk-jan Mollema, who found it, put the blast radius at every tenant in the world.
Before these two: Storm-0558's stolen signing key reading State Department mail, a leaked credential opening Okta's support system. My colleague Dima Donhin traced how identity became the attack surface; the pattern underneath is narrower: many entry vectors, one destination - the vault holding 100% of the key that signs your tokens.
Microsoft patched the deserializer, as it will patch whatever comes next. But a server-side fix closes an entry vector; it does not fix the fundamental flaw - the architecture. The single key sits where it always has - whole, in the vendor's sole custody - so the next backend RCE is an existential threat to every organization on the platform.
"The vendor must hold the whole key" is not physics - it is a design assumption, one our founding manifesto said will keep getting attacked until somebody removes it. And as agents come to outnumber the humans vouched for by that same key, it ages worse every quarter.
NewCore: Zero Blast Radius by Design
Nine days before this CVE, I published a blog post with an uncomfortable premise: assume NewCore is completely compromised - infrastructure, database, backups, all of it. Its scenario table has a row labeled "Gains full code execution inside the vendor." Yesterday, Microsoft ran that scenario in production. I did not expect confirmation this fast.
I could afford that because of how Secure Split Key (SSK) is built: NewCore only ever holds half of the key. The key signing your SAML assertions and OIDC tokens is split between two organizations - ours on our side, yours in your perimeter - never assembled anywhere, not even during signing.
Run the same attack against that design and it dies at the signature: total code execution across NewCore yields one mathematically useless fragment. Partial signatures all day; no application accepts one. Zero valid tokens. Zero forged logins. They can take configuration data - never the ability to sign as you.
Same Attacks, Different Physics
| Attack scenario | Legacy centralized IdP | NewCore with SSK |
|---|---|---|
| Unauthenticated RCE on vendor backend (CVE-2026-69836 class) | Full Tenant Compromise. Code execution beside the signing infrastructure mints valid tokens for any user, in any tenant. | Zero Blast Radius. The attacker holds one inert key share; not a single login completes. |
| Token validation logic flaw (CVE-2025-55241 class) | Silent Global Admin Takeover. Vendor-minted tokens are trusted as-is: cross-tenant impersonation, no MFA, no victim-side logs. | Forgery Dead on Arrival. A token missing your co-signature fails verification; the vendor alone cannot manufacture trust. |
| Stolen vendor database or backups | Total Key Exposure. Key material is gone; every token signed since is suspect. | Metadata at Worst. No complete key exists to exfiltrate; your trust anchor was never in the database. |
| Vendor insider threat | Insider God Mode. Internal trust converts directly into customer-facing authority. | No Signature Without You. Internal access never adds up to a valid token without the share you hold. |
The table is the whole argument. Bugs happen to everyone; what differs is what a bug is worth to whoever finds it. And what SSK removes is the scenario this week reran: god mode minted from outside, by breaching someone you trusted.
The Question to Ask Your IdP Vendor on Monday Morning
Perimeter patching is whack-a-mole, with your tenant as the stake. The only way out is structural: no whole key left for anyone to reach. No SOC 2 report will tell you whether your vendor is built that way; no security questionnaire asks. So ask it yourself:
"If an attacker gains full remote code execution on your infrastructure tonight, can they produce even one valid token for my tenant?"
For every centralized IdP on the market, the honest answer is yes. Twelve months and two perfect-10 CVEs say that is no longer acceptable. Your vendor should be a dead end for attackers, not a road to you. Demand an architecture where the answer is a mathematical no. We built one.