Microsoft Said It Was Exploited. Then It Wasn’t. Your Tenant Still Can’t Tell You Which.

Verification asymmetry is what happens when the only party who can confirm whether your organization was compromised is the same party whose public account of the compromise changed within a single news cycle — and that is exactly what happened this week with Microsoft’s Entra ID.

On Thursday, August 20, Microsoft disclosed CVE-2026-69836: a maximum-severity vulnerability in Entra ID, the identity platform behind sign-in and access control for Microsoft 365, Azure, and every connected third-party application riding on it. CVSS 10.0. Deserialization of untrusted data, allowing an unauthenticated attacker to execute code over the network with no privileges and no user interaction required. Discovered internally, by Microsoft’s own principal security engineer. Microsoft says the flaw was remediated server-side — no customer patch exists because the fix lives entirely inside Microsoft’s own infrastructure, applied before the advisory ever became public.

That last part is worth sitting with before going further. “No action required” is true as a statement about patching. It says nothing about exposure. A vulnerability that lived, however briefly, in a platform your organization does not operate, cannot inspect, and cannot independently audit is not the same condition as a vulnerability in your own stack that you closed yourself. The absence of a patch step doesn’t mean the absence of a question.

This is the structural condition every organization running Entra ID already accepted the moment it outsourced identity to a fully managed cloud service, and it’s worth naming plainly rather than treating as a surprise. A self-hosted identity system, however imperfect, at least generates an incident record its own owner controls end to end. A fully managed one generates a record its owner controls, full stop — and the customer’s only view into that record is whatever the vendor chooses to disclose, in whatever form the vendor chooses to disclose it. That arrangement works fine right up until the disclosure itself becomes the thing in question.

The Reversal

Here is the part that actually makes this post-worthy, and it isn’t the CVSS score.

Microsoft’s initial advisory, published Thursday, marked the vulnerability’s Exploitability Assessment as “Yes” — under active attack. Within the same news cycle, Microsoft revised that field to “No.” A company spokesperson told reporters the vulnerability “was not exploited in the wild,” offering no technical explanation for either the original assessment or the reversal — no timeline, no indicator of compromise, no account of what changed between the first version of the advisory and the second.

Several outlets updated their coverage to reflect the correction. At least two did not, and are still circulating the original “exploited” framing as of this writing. That gap is itself a small, concrete demonstration of the underlying problem: even the secondary reporting on this incident couldn’t hold a stable, verified account of what happened — and none of it was ever independently verifiable by the organizations actually running Entra ID tenants.

To be precise about what is and is not established here: Microsoft asserted exploitation, then retracted the assertion. No independent party has confirmed either version. No attack timeline exists publicly. No affected tenant has been named. This piece takes no position on which version was accurate — because no external party is in a position to.

That gap between the two versions, and the total absence of any independent way to close it, is the verification asymmetry this piece is actually about — not the CVE score, and not which version of the advisory was correct.

This is not a criticism of Microsoft’s disclosure process itself. Publishing a CVE for a fully self-remediated, no-action-required issue is, if anything, more transparency than many vendors offer for cloud-side fixes that never surface publicly at all. The problem isn’t that Microsoft said something and then corrected it — corrections happen, and a company owning a mistake in public is not automatically a mark against it. The problem is structural, and it’s the verification asymmetry running underneath every part of this: there is no mechanism by which a customer, or a journalist, or an independent researcher could have adjudicated between the first version and the second on their own evidence. The correction had to be taken on faith, exactly like the original claim did.

The Verification Asymmetry Underneath Identity Boundary Inversion

Rack2Cloud has already named the condition where identity — not network topology — becomes the boundary that actually determines whether an action is authorized. That’s Identity Boundary Inversion: the recognition that a change or a migration can survive a topology shift but fails the moment identity state is inconsistent or unverified.

This is a different problem, sitting one layer beneath it — a verification asymmetry rather than a boundary-location question. Identity Boundary Inversion assumes your organization can at least observe the boundary it’s now depending on. This week’s incident is about a boundary an organization cannot observe at all, because the party who owns and operates it is also the sole source of any claim about its integrity — and that source’s own claim changed without explanation. It’s closer kin to the territory covered in Your Cloud Isn’t Compromised. Your Vendor Is. Now What? — a third party’s compromise leaving delegated authority technically unaffected — than to Identity Boundary Inversion, but it isn’t that either: that post’s condition is about authority you granted and can at least see. Here, there is no delegated credential to audit, no access grant to revoke — only a vendor’s own infrastructure, and a vendor’s own retracted claim about what happened to it. Anyone tracing how control-plane ownership questions compound as more of the stack gets outsourced will recognize the shape of this one even though the mechanism is new.

This isn’t the first time Rack2Cloud has documented a gap between what a system asserts and what it can prove. GhostApproval covered evidence that exists, is trusted, and is presented as authoritative without accurately representing the action it approved. The Access Was Real. The Authorization Wasn’t. covered self-attestation asking the subject to supply the fact a control exists to verify independently. Identity Directories Have Become An Unmonitored Intelligence Source covered a read-layer operation that looks legitimate by design and is governed almost nowhere. This post is the same family of failure at vendor scale: an assertion nobody outside the asserting party can check.

What a Tenant Can Actually Establish

An organization running Entra ID can pull its own sign-in logs, its own audit trail, its own conditional-access reports for the window around August 20. That’s a real, legitimate step, and it’s the correct one to take. But it’s worth being honest about its limits.

Those logs are generated by the same platform whose public exploitation assessment changed once already, without explanation, in the same week. A clean log doesn’t prove the absence of a problem in a control plane you don’t operate — it proves the absence of anything the platform’s own telemetry was built to surface, if you trust that telemetry was operating correctly during exactly the window in question. That trust is not unreasonable. But it is trust, not verification, and the two are not interchangeable — the platform generating those logs is operated by the same party whose public exploitation assessment changed without an explanation customers could independently adjudicate.

This is verification asymmetry in its plainest form: the vendor holds every fact that would resolve the question, and the customer holds none of the tools that would let them check the vendor’s answer against anything else. It’s the same structural question that runs through most of Rack2Cloud’s cloud strategy writing on vendor dependency — not whether a provider is trustworthy, but whether “trustworthy” is even a claim a customer is positioned to verify.

None of this argues for abandoning managed identity platforms, and this piece isn’t making that case. The practical response sits at the governance layer, not the technical one: vendor risk reviews that ask what advisory-correction process exists and how it’s disclosed, contractual language that addresses transparency during exactly this kind of status reversal, and an internal posture that treats “fully mitigated, no action required” as the start of a governance question rather than the end of one. None of that closes the verification asymmetry itself — it can’t be closed from the customer side, structurally — but it at least puts the asymmetry on the record before the next reversal, rather than after it.

Additional Resources