Microsoft patches a 10.0-rated RCE in Entra ID and tells customers to do nothing
A deserialization flaw in Entra ID, Microsoft’s cloud identity service, allowed unauthenticated remote code execution — rated CVSS 10.0 and fixed server-side with no customer action. CISOs need to understand what "no action required" actually demands of them.
August 21, 2026. CVSS 10.0. Deserialization. Microsoft patched a remote code execution vulnerability in Entra ID, its cloud identity service — and told customers to do nothing. The flaw, CVE-2026-69836, is rated CVSS 10.0, the maximum score, and stems from the deserialization of untrusted data that let an unauthenticated attacker execute code over the network.
The line to remember is not technical. It sits in Microsoft’s advisory: “This vulnerability has already been fully mitigated by Microsoft. There is no action for users of this service to take. The purpose of this CVE is to provide further transparency.” An invisible patch, for a flaw nobody can verify.
The flaw at the heart of identity
Entra ID — formerly Azure Active Directory — is the service that authenticates logins and controls access to Microsoft 365, Azure, and thousands of connected third-party apps. It is the central identity component at the vast majority of enterprises.
Deserialization of untrusted data means the application turns serialized, attacker-controlled input back into live objects or code structures, without sufficient validation. Here the consequence is the gravest possible: an unauthenticated attacker can execute code inside the identity service itself.
The flaw was discovered by Robert Fitzpatrick, a Microsoft principal security engineer. The vector is remote, account-free, and interaction-free — the triplet that justifies the 10.0.
A contradictory timeline
The public record is murkier than the advisory suggests. Help Net Security first reported the flaw as “exploited in the wild”, before Microsoft corrected an “Exploited” flag attached to the CVE. The result: the vulnerability is not in CISA’s KEV, the reference list of actively exploited flaws.
That back-and-forth matters. A withdrawn “exploited” flag, an absence from the KEV, and a patch “already applied” server-side leave a CISO with no independent way to know whether exploitation actually happened, or for how long.
Microsoft has not disclosed who was behind any exploitation, when it began, how many organizations were affected, or what attackers did once inside the service. The “further transparency” stops at the statement itself.
The opacity of the cloud patch
This is the core point. A server-side patch on a multi-tenant service you do not deploy is, by nature, invisible: no binary to download, no version to check, no reboot to schedule. You cannot confirm the fix is in place other than by trusting the vendor.
That opacity inverts the balance of traditional security. On an on-premise product, you control the patch; on a cloud service, you control only your signals — sign-in logs, audits, permission changes. Your defense perimeter shifts from patching to detection.
It is also a lesson in shared responsibility. Microsoft patches the service; you patch what the service cannot patch for you: accounts, roles, conditional access, and monitoring.
What “no action required” actually requires
The phrase “no action required” is true in the narrow sense of the patch. It is false in the operational sense. Here is what it actually demands of a team that takes identity security seriously:
- Enable and retain Entra ID sign-in and audit logs — they are the only trace you hold;
- Hunt anomalies: risky sign-ins, unusual locations, unexpected app consents, privilege elevations;
- Harden conditional access and Privileged Identity Management (PIM): an attacker who touched the identity service is only worth as much as their ability to pivot to high-privilege accounts;
- Review OAuth consents and connected third-party apps — a classic rebound vector after an identity compromise.
// Hunt risky sign-ins in Entra ID logs (Microsoft Sentinel / Log Analytics)
SigninLogs
| where RiskLevelDuringSignIn == "high" or RiskState == "atRisk"
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location
| order by TimeGenerated descThe query does not prove this CVE was exploited. It proves what matters more: that your detection works when an identity signal stands out from the noise.
Shared responsibility, identity edition
The Entra ID flaw crystallizes a shift in enterprise security. For two decades, a CISO’s job on a CVE was clear: identify, prioritize, patch, verify. The cloud CVE inverts the sequence: nothing to patch, everything to monitor, and an act of faith toward the vendor as the only substitute for verification.
The residual risk is not the flaw — it is fixed. It is the uncertainty: with no technical detail, no exploitation timeline, no attribution indicator, you cannot tell whether the incident stopped at the patch or left backdoors in tenants.
The answer is not to reject the cloud. It is to harden the control you keep: identity visibility deep enough to detect what you can no longer patch, and a least-privilege discipline that limits the damage if identity falls.
A deeper trend runs underneath: server-side cloud RCEs are systematically under-counted in the public record, because they carry no customer patch and leave no install footprint. The tools that measure your cloud posture — CSPM, identity-hygiene scanners — cannot see a flaw the vendor already fixed in its own service. What they can see is the access pattern a would-be attacker leaves behind, which is why identity telemetry, not vulnerability scanning, is the right lens here.
What the retracted “Exploited” flag reveals
The wobble over exploitation is not editorial vanity. It exposes an evidentiary asymmetry: Microsoft holds the service telemetry — logins, behavior, payloads — but does not share it beyond a binary flag that it later revised. The customer holds only their own tenant logs.
That asymmetry has concrete consequences. With no timeline and no exploitation scope, you cannot answer the question a board will inevitably ask: “were we affected?” The only honest answer is: “we have no way of knowing” — an untenable position over time.
Two levers soften the imbalance. First, external attestation: SOC 2, ISO 27001, and contractual incident-notification commitments become the only levers that force a cloud vendor to document what happened. Second, detection redundancy: do not lean on the vendor’s signal, but keep independent identity telemetry — export logs to a SIEM you control, alert on role changes and consents.
The Entra ID patch is settled. What is not settled is an organization’s ability to verify an incident that happened inside a third party. That ability — not the flaw — is what will make the difference next time, and it is exactly the muscle a CISO should be building between crises.
Verdict
Your job is not to patch — it is to monitor. Enable and centralize Entra ID sign-in logs if you have not already, then hunt risky sign-ins and permission changes over a rolling window. It is the only trace you have left of a patch you will never see.
Then reduce the value of an identity compromise. Apply conditional access and Privileged Identity Management until a compromised account is no longer enough to reach your sensitive resources. The Entra ID flaw is patched; yours — the visibility gap — is only fixed if you treat it.
The lesson fits in one line: in the cloud, patching is a matter of trust, detection a matter of evidence. A CISO cannot patch what they do not deploy — but they can see what happens inside it. For the CISO, the takeaway is not this CVE: it is that the next cloud RCE will arrive the same way, already patched and already invisible, and answerable only through the logs you chose to keep.