On August 20, 2026, Microsoft published CVE-2026-69836: a CVSS 10.0 vulnerability in Microsoft Entra ID, described as “deserialization of untrusted data in Microsoft Entra ID allows an unauthorized attacker to execute code over a network.” The weakness class is CWE-502. No authentication, no user interaction, remote code execution against the cloud identity service a very large share of the world’s enterprises use as their authentication control plane.

The flaw was found internally, credited to Microsoft Principal Security Engineer Robert Fitzpatrick. Attached to the maximum possible severity score was the least actionable guidance a security team can receive: “There is no action for users of this service to take.” It had been fully mitigated service-side before publication, and Microsoft said the CVE was issued purely “to provide further transparency.”

Then the disclosure got worse in an instructive way. The bulletin as first published carried the exploitation flag set to “Exploited: Yes.” After press inquiry, Microsoft corrected it to “Exploited: No.” Several outlets had already published the exploited-in-the-wild version, and incident response teams that read the bulletin in its first hours convened on a fact that was not true.

This article is not about patching, because there is nothing to patch. It is about the governance problem underneath: what a vulnerability management program does with a critical finding it cannot remediate, verify, log, or evidence — and how to keep an auditor from finding an open CVSS 10.0 in your register with no closure trail behind it.

What Was Actually Disclosed, and What Was Not

Confirmed: a CWE-502 unsafe deserialization defect in Entra ID; CVSS 10.0; unauthenticated network-reachable RCE; found internally; remediated in Microsoft’s own infrastructure; no customer configuration change required; not exploited in the wild.

Not disclosed: which component was affected; what tenant boundaries the code execution could have crossed; how long the defect existed in production; what telemetry Microsoft reviewed to conclude non-exploitation, and how far back it reaches; whether any tenant-scoped indicators exist that a customer could hunt for.

That second list is the compliance problem. A vulnerability in software you run generates artifacts: a version number, a patch record, a scan result showing the finding cleared. A vulnerability in a service you consume generates a paragraph. You are asked to accept a statement in place of evidence, on a control sitting underneath every other control you operate.

This is not a first. In September 2025, Microsoft fixed CVE-2025-55241, also CVSS 10.0, in which undocumented “Actor” tokens issued by one tenant were accepted by the legacy Azure AD Graph API in other tenants — enabling impersonation of any user, up to Global Administrator, in effectively every Entra ID tenant. Two details from Dirk-jan Mollema’s analysis matter enormously here: Actor-token authentication bypassed MFA and Conditional Access, and the relevant Graph API calls produced limited logging, making exploitation very difficult for a customer to detect. Microsoft fixed it service-side; customers had no action to take then either.

Two maximum-severity identity-plane defects in eleven months, both remediated invisibly, both leaving customers without means of verification. Your program’s position on this class of finding needs to be a written position, because it is a recurring event rather than a curiosity.

The Shared Responsibility Model Meets Your Vulnerability Management Policy

Nearly every vulnerability management policy contains a sentence of this shape: “Critical vulnerabilities (CVSS 9.0–10.0) shall be remediated within [7/14/30] days of identification.” It satisfies PCI DSS v4.0 Requirement 6.3.3, SOC 2 CC7.1, ISO/IEC 27001:2022 Annex A.8.8, and the risk-management expectations of NIS2 Article 21(2)(e). It works fine for software you operate.

Applied to CVE-2026-69836 it produces an absurdity. The finding enters your register at CVSS 10.0 and the SLA clock starts. There is no remediation action available, no patch to deploy, no scan that will register the state change, no configuration you can attest to. At day 15 or day 31, your own policy classifies you as non-compliant with your own SLA on a maximum-severity vulnerability — because your provider fixed it before you knew it existed.

Two common responses are wrong. Don’t record it: if there is no action, why track it? Because an assessor asking “how did your organisation become aware of and respond to CVE-2026-69836?” is asking a question your program should be able to answer, and silence is indistinguishable from ignorance. Record it and let it age: an open CVSS 10.0 sitting in the register for six months with no closure note reads as an SLA breach the organisation noticed and ignored.

The right answer is an explicit disposition class in the policy. Add a provider-remediated category: a vulnerability in a third-party managed service where remediation is performed exclusively by the provider and no customer-side technical action is available or required. It needs its own lifecycle — not the patch SLA, but an equivalent set of obligations that produce evidence:

  • Intake within the same window as any other critical finding. The clock that starts is not a remediation clock but an assessment and disposition clock; 48 to 72 hours to a written disposition is defensible.
  • Provider-statement capture. Archive the advisory as published, with retrieval timestamp and a hash or screenshot. This matters more than it sounds, as the next section explains.
  • Detective review of what in your environment would have detected or limited exploitation — and whether log retention reaches back far enough to look at all.
  • Formal disposition with named owner and date, plus risk-register linkage: the CVE closes, but the structural risk — dependence on an identity provider whose defect lifecycle is opaque to you — stays open as a standing entry.

The point is to make the difference between “we cannot act” and “we did not act” legible in your records, because those two states look identical from outside and only one is defensible.

Identity Is Not One System. It Is the Assumption Underneath Every Control.

A CVSS 10.0 in Entra ID differs categorically from one in a departmental application, because Entra ID is not in scope of your access control framework. It is your access control framework. Consider what code execution in the identity plane does to control statements you have already asserted:

SOC 2 Common Criteria, CC6 series. CC6.1 (logical access security over protected assets), CC6.2 (user registration and credential issuance), CC6.3 (role modification and removal), CC6.6 (threats from outside system boundaries), CC6.7 (restriction of information movement). In a Microsoft-centric enterprise every one of those is implemented by Entra ID, and your system description names Conditional Access, MFA enforcement and Privileged Identity Management explicitly. If the platform enforcing those policies can be made to execute attacker-controlled code, the controls have not failed in the ordinary sense — their substrate has been shown to be conditionally untrustworthy.

ISO/IEC 27001:2022 Annex A. A.5.15 (access control), A.5.16 (identity management), A.5.17 (authentication information), A.5.18 (access rights) and A.8.5 (secure authentication) are all delegated in practice to the identity provider. A.5.19 through A.5.23 — supplier relationships and cloud service security — are the clauses actually load-bearing here, and usually the thinnest part of an ISMS.

The MFA point deserves emphasis. The 2025 Actor-token flaw bypassed MFA and Conditional Access outright. Organisations that spent two years migrating to phishing-resistant authentication correctly hardened the credential — but a defect in the token-issuing service sits behind the credential, and no amount of passkey deployment constrains it. We examined the credential-layer half of this in Pass-the-Passkey and what phishing-resistant MFA does and does not promise; CVE-2026-69836 is the platform-layer half, and only one of the two is yours to fix.

So your identity provider belongs in the risk register as a named single point of failure, with a documented statement of what fails if it is compromised and what realistically does not. Few entries say this out loud. They should, because the honest answer for most organisations is “essentially everything, simultaneously, with no independent detection.”

Assurance You Cannot Obtain, and Assurance You Can

The customer’s position: no patch to verify, no indicators to hunt, no provider-plane logs, no independent confirmation of the non-exploitation finding, no disclosed exposure window. What is left?

Provider attestations — real but bounded. Microsoft’s SOC 2 Type II and SOC 1 reports, ISO/IEC 27001, 27017 and 27018, and FedRAMP High authorisation evidence that a vulnerability management process, secure development lifecycle and incident response capability exist and were tested over a period. They do not evidence that any particular defect was absent or any remediation complete. Read the Complementary User Entity Controls (CUEC) section — where the provider states in writing which controls remain yours, and the part most organisations never open.

CSA STAR and the CAIQ. The Cloud Security Alliance STAR Registry entry and the CAIQ mapped to CCM v4 give a control-level assertion set, including the TVM (Threat and Vulnerability Management) domain covering the provider’s own vulnerability handling and disclosure practice. A document, not proof — but one you can cite in a control narrative.

DORA Article 30 and the register of information. For EU financial entities, the Digital Operational Resilience Act made this a contractual matter rather than a hope. Articles 30(2) and 30(3) require ICT third-party contracts supporting critical or important functions to include provisions on incident reporting and provider assistance, service level descriptions, access/inspection/audit rights, and exit strategies. Article 28(3) requires the register of information on all contractual arrangements, so the dependency is formally enumerated and reportable to the competent authority. The Article 30(3)(a) incident-assistance obligation is precisely what you invoke when a provider advisory is this thin — see our DORA and NIS2 2026 enforcement analysis for how supervisors are reading these terms in practice.

NIS2 Article 21(2)(d) makes supply chain security an explicit risk-management measure, requiring entities to account for vulnerabilities specific to each direct supplier and the quality of its cybersecurity practices — a provider’s disclosure practice, including whether its advisories carry accurate metadata, sits squarely within that. In the US, the Interagency Guidance on Third-Party Relationships (OCC/Federal Reserve/FDIC, June 2023) and the FFIEC IT Examination Handbook require ongoing monitoring commensurate with risk, with explicit attention to concentration and subcontractor dependencies.

None of this gives you verification. All of it gives you a defensible basis for reliance, which is the actual standard. The distinction to write down: “the provider fixed it” is not a compensating control. A compensating control is something you operate, can test, and that produces evidence. Provider remediation is an assurance dependency, and presenting it to an assessor as anything else will not survive contact with a competent one.

The “Exploited: Yes” Correction Cost Real Money

The metadata error is the part of this event with a direct operational cost and a fixable governance answer. An exploitation flag is not a descriptive field. It is a trigger. In most mature programs, “actively exploited” on a CVSS 10.0 affecting a tier-zero system starts a defined sequence: incident commander assigned, bridge opened, threat hunt scoped, executive notification prepared, and — for regulated entities — an early assessment of whether reporting clocks are engaged. NIS2 Article 23 requires an early warning within 24 hours of awareness of a significant incident; DORA Article 19 runs a similarly short supervisory timetable; SEC Item 1.05 requires a materiality determination without unreasonable delay. Teams reading the first version of this bulletin had reason to start all of it.

Then the flag flipped to “No,” and every one of those teams stood down a mobilisation that should never have started, on a workday nobody gets back. The lesson is not that vendors should be perfect, but that your escalation logic should not take a single unverified vendor field as its sole input. Write the rule down:

  • Define a corroboration window. For an exploitation flag on a provider-managed service with no customer action available, allow a defined window — two to four hours is typical — before full mobilisation. Corroborate against CISA KEV, the provider’s own MSRC blog post (distinct from the CVE record), national CERT advisories, and at least one independent intelligence source with original telemetry rather than a rewrite of the same bulletin.
  • Distinguish mobilisation tiers. Tier one — assign an owner, capture and timestamp the advisory as published, begin applicability assessment, start log review — costs little and triggers immediately. Tier two — incident declaration, bridge, executive notification, regulatory clock assessment — waits for corroboration or for the finding to be customer-actionable. The tier-one snapshot matters: when a vendor silently edits a field, your record of what it said when you acted is the only defence against an unexplainable decision in a post-incident review.
  • Close out a stood-down incident properly. Do not delete the ticket. Convert it to a closed record stating what was observed, when, from which source; what actions were taken; what changed the assessment, with the corrected source and timestamp; and the disposition. Escalating on published information and de-escalating on corrected information is evidence of a functioning process. A vanished ticket is evidence of nothing.
  • Feed it back into provider monitoring. Under DORA Article 28 and NIS2 Article 21(2)(d), the quality of a provider’s security communications is a legitimate assessment input. Log the metadata error in the provider performance record, alongside the observation that the correction followed press inquiry rather than proactive notification.

Concentration Risk and Why Regulators Are Circling

The same identity plane sits underneath an extraordinary share of the economy at once, which makes a defect in it a correlated risk across every sector simultaneously — the definition of systemic.

Regulators reached this conclusion independently. DORA’s oversight framework for critical ICT third-party providers — Articles 31 to 44 — lets the European Supervisory Authorities designate providers as critical and subject them to direct oversight, including inspections, recommendations, and ultimately the power to require financial entities to suspend or terminate use of the provider. The Article 31(2) criteria are explicitly about systemic impact and substitutability; a cloud identity provider serving most EU financial entities is the paradigm case the framework was drafted for.

The EU Cyber Resilience Act adds a second front: its vulnerability-handling and coordinated-disclosure obligations on manufacturers of products with digital elements, including an Article 14 24-hour early warning to ENISA for actively exploited vulnerabilities, progressively make disclosure quality a regulatory matter rather than a courtesy. And NIS2 pushes the analysis down to the entity: your management body is personally accountable under Article 20(1) for approving and overseeing supply chain risk measures, so “we use Microsoft, so it’s fine” is not a risk assessment. We treated the structural version of this argument in vendor concentration as a counterintelligence problem; the identity plane is its sharpest instance.

The corollary is uncomfortable: for most organisations there is no meaningful diversification strategy for the identity provider. What is achievable is bounded blast radius — break-glass accounts that do not depend on the primary identity plane, out-of-band administrative paths for critical systems, a tested exit and continuity plan rather than contractual boilerplate, and documentation of what cannot be mitigated. That last item is not a failure: documented, accepted, board-visible residual risk is a mature outcome, and undocumented residual risk is the finding.

A Template Register Disposition

Finding ID: VM-2026-XXXX Source: MSRC advisory, CVE-2026-69836, published 2026-08-20; archived at [evidence link], retrieved [time, UTC]. Description: Deserialization of untrusted data (CWE-502) in Microsoft Entra ID permitting unauthenticated RCE. CVSS base score 10.0. Found internally by Microsoft. Applicability: Applicable. Entra ID is the primary identity provider for [N] users and [N] applications, including federation for [tier-zero systems]. Affected component not specified; assessed at service level. Exploitation status: Advisory initially published with exploitation flag “Yes”; corrected by the provider to “No” following media inquiry. Both versions archived. Corroboration checked at [time]: CISA KEV — not listed; MSRC blog — no separate post; [national CERT] — no advisory. Final assessed status: no evidence of exploitation in the wild. Customer remediation available: None; provider states the vulnerability is fully mitigated service-side. Disposition class: Provider-remediated (Vulnerability Management Policy §X.X). Assurance basis: Provider SOC 2 Type II [period], ISO/IEC 27001 and 27017 certificates [refs], FedRAMP authorisation [ref], CSA STAR/CAIQ entry [ref]. CUEC section reviewed; none applicable. Contractual basis: [MSA/DPA clause refs]; DORA Article 30 terms at [clause ref] where in scope. Detective review performed: Entra ID sign-in and audit log review for [range], covering anomalous privileged role assignments, new service principal creation, application credential additions and Conditional Access policy changes. Log retention available: [N] days — flag where that is shorter than the plausible exposure window, since it is itself a finding. Results: [findings]. Reviewer: [name], date. Residual risk: Cannot independently verify provider remediation, cannot obtain provider-plane telemetry, no disclosed exposure window. Accepted by [risk owner] on [date]; escalated to [committee] on [date]. Linked structural risk entry: RR-XXX — identity provider concentration and opacity of the provider-side vulnerability lifecycle. Standing entry, reviewed [frequency]. Status: Closed — provider-remediated. Closed by [name], [date].

What to Say in the Next Questionnaire

Questionnaires, regulator information requests and insurer applications will ask about this class of event, usually as “describe your process for managing vulnerabilities in third-party cloud services.” Do not answer with the patch SLA. Answer with the structure: that the program distinguishes customer-remediable from provider-remediated vulnerabilities, the latter having a defined intake, disposition and evidence path with named ownership, cited by policy section number; that a corroboration rule for vendor exploitation flags exists, because vendor advisory metadata has been observed to be incorrect; which assurance artefacts are relied on, documented as an assurance dependency rather than asserted as a compensating control; which contractual provisions — DORA Article 30 terms, incident assistance, audit rights — make that reliance enforceable; and that identity provider concentration is a standing risk register entry with board visibility, with break-glass and continuity arrangements tested on a stated cycle.

That answer is stronger than any claim of technical control over the finding, because it is true and evidenced. Where you cannot control, govern; where you govern, document. For the routine half of the Microsoft patch cycle — the vulnerabilities that are yours to fix — the discipline is different, and we covered it in the August 2026 Patch Tuesday risk-based prioritisation analysis.

Conclusion

CVE-2026-69836 will be forgotten in a quarter. Nobody was breached, no customer had anything to do, and the disclosure was a good-faith act of transparency most providers would have skipped entirely. The governance lesson survives the event. Cloud consumption has quietly relocated a large fraction of an enterprise’s most severe vulnerabilities into a space where the enterprise can observe them but not act on them, verify them, or evidence their closure. Vulnerability management programs were designed for a world where severity implied action. That implication has broken, and it breaks first at maximum severity, because the most critical shared infrastructure is the most abstracted away.

The organisations that handle the next one well will not be the ones with better tooling. They will be the ones whose policy already had a place to put a CVSS 10.0 with no patch, whose escalation rules did not fire on a single unverified vendor field, and whose risk register already said in writing that the identity plane is a single point of failure — accepted and bounded, rather than quietly assumed away.

Sources: Help Net Security — Microsoft patches critical Entra ID vulnerability (CVE-2026-69836), The Hacker News — Microsoft Patches Severe Entra ID Flaw (CVSS 10.0) Allowing Remote Code Execution, Cybersecurity Dive — Microsoft discloses maximum severity flaw in Entra ID, dirkjanm.io — One Token to rule them all: obtaining Global Admin in every Entra ID tenant via Actor tokens (CVE-2025-55241), SecurityWeek — All Microsoft Entra Tenants Were Exposed to Silent Compromise via Invisible Actor Tokens

This article is provided for informational purposes only and does not constitute legal advice.