On 20 August 2026 Microsoft published an advisory for CVE-2026-69836, a remote code execution vulnerability in Microsoft Entra ID — the cloud identity service formerly called Azure Active Directory. The CVSS 3.1 base score is 10.0, the maximum. The root cause is deserialization of untrusted data (CWE-502), reachable without authentication over the network. The finder credited in the advisory is Robert Fitzpatrick, a Microsoft principal security engineer, so this was found internally rather than reported from outside.
Then the advisory said something that turned out to be false. The Exploited field was published as Yes. On 21 August, after The Hacker News queried it, Microsoft issued revision 2 of the advisory: "Corrected Exploited to No. This vulnerability was not exploited in the wild. This is an informational change only." CERT-FR followed the same path — advisory CERTFR-2026-AVI-1074 was published on 21 August repeating the exploitation claim, then revised on 24 August to withdraw it.
For roughly a day, the public record showed a maximum-severity, unauthenticated code execution flaw under active attack in the system that authenticates most enterprise Microsoft estates. Security teams that convened a bridge call on 20 August spent it on a fact that was not true.
Why the score is 10.0 and why there is nothing to install
The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Network attack vector, low complexity, no privileges, no user interaction, and full impact on confidentiality, integrity and availability. The element that pushes it from 9.8 to 10.0 is S:C — Scope: Changed: the vulnerable component and the impacted component are not the same. In an identity service, that is the whole point. Code execution in the platform that issues tokens does not stay inside that platform.
Microsoft's own temporal score was 8.7, using E:U (exploit code unproven), RL:O (official fix available) and RC:C (confirmed). CISA's Vulnrichment decision, recorded on 21 August, reads Exploitation: none, Automatable: yes, Technical Impact: total. EPSS on 31 August 2026 sat at 0.0156 — around the 73rd percentile.
The advisory carries the tag exclusively-hosted-service and, under Customer Action, one line: "Not required. The vulnerability documented by this CVE requires no customer action to resolve." Microsoft states the issue was already fully mitigated in its infrastructure and that the CVE exists to provide transparency, under the cloud service CVE programme it launched in 2024.
That is worth acknowledging plainly: the deal a tenant makes when it moves identity to a hosted control plane worked here. There was no maintenance window, no emergency change, no fleet to patch.
One more detail is worth recording, because it shows how far a wrong flag travels. The CVE was added to CISA's Known Exploited Vulnerabilities catalogue on 21 August 2026 with a remediation due date of 24 August. We checked the KEV feed for this article: as of the 31 August 2026 release, catalogue version 2026.08.31 with 1,687 entries, CVE-2026-69836 is no longer listed. It was added while the vendor flag read Yes, and it is gone now that the flag reads No.
What you own in a hosted identity service
"No customer action" is accurate about the code and misleading about the risk. The vulnerability was in Microsoft's service. The configuration, the privileges, the trust relationships and the evidence are yours.
The honest question raised by this CVE is not "did we patch". It is: if this had been exploited, could we have answered "was our tenant affected" from telemetry we hold? For most organisations, the answer depends on decisions made months earlier.
Entra ID retains sign-in and audit logs for 30 days on P1 and P2 licences, and 7 days on the free tier. That is the default. If you have not configured diagnostic settings to export those logs to a Log Analytics workspace, a SIEM or Microsoft Sentinel, your ability to investigate an identity incident expires on a rolling one-month window — and diagnostic settings themselves require P1 or P2. An investigation into a suspected token-issuance compromise that starts six weeks late has no data to work with.
Four things are worth checking in your own tenant, none of which are about this CVE specifically:
- Log retention and export. Where do Entra sign-in logs, audit logs and provisioning logs go, how long are they kept, and who can query them at two in the morning?
- Privileged role hygiene. How many accounts hold Global Administrator permanently rather than eligible-on-request through Privileged Identity Management? Which of them are excluded from conditional access policies? Are break-glass accounts documented, stored properly and tested?
- Service principals and app consent. Enterprise applications with application-level Graph permissions do not require a user, a password or an MFA prompt. They are the least reviewed part of most tenants and the part that survives a password reset.
- Conditional access as written, not as intended. Policies accumulate exclusion groups. A test group created for one project two years ago is still exempt from device compliance requirements, and nobody owns the review.
None of that is found by scanning a web application. Identity configuration review belongs in a defined scope, alongside the cloud and identity platform assessment and the internal and external penetration test that verifies what the configuration actually permits.
Where this lands under NIS 2
For essential and important entities in Romania, NIS 2 is transposed through Government Emergency Ordinance no. 155/2024, approved with amendments by Law no. 124/2025. Three obligations touch this case directly.
Risk management measures, Article 21 of Directive (EU) 2022/2555, explicitly include supply chain security and the security of relations with direct ICT suppliers and service providers. An identity provider is the most consequential ICT service provider an organisation has. It belongs in the asset inventory and in the risk analysis as a named dependency, with the residual risk that the tenant cannot patch it written down and accepted at the right level.
Management accountability, Article 20, means the approval and oversight of those measures sits with the management body, not with the IT team. "Our identity provider had a 10.0 and we had no way to verify our own exposure" is a governance finding, not a technical one.
Incident reporting, Article 23, runs on the 24-hour early warning, 72-hour notification and one-month final report cycle, filed with DNSC through the PNRISC platform. The four checks above are what make those deadlines achievable. Reporting obligations do not pause because the root cause was in a supplier's code.
The wider lesson: a vendor flag is a trigger, not a finding
Exploitation-aware prioritisation is the right model — a 7.0 actively used by a real threat actor outranks a dozen unexploited 9.8s. This incident shows the operational cost of building that model on a single field from a single source.
For hosted services in particular, there is no customer-side patch to gate the response on, so the advisory field is the trigger. That makes a written rule worth having: when a vendor flags exploitation in a service you consume rather than run, the first action is to verify against your own telemetry and, where available, a second source — the KEV catalogue, the national CERT, the vendor's CSAF feed — before declaring an incident. Advisory revisions are published quietly. Someone has to own re-reading them.
A security audit and risk assessment that treats the identity layer as a governed dependency, and a documented NIS 2 and DORA readiness position, are what turn an advisory like this from a scramble into a recorded decision.
This article is general information and does not constitute legal or regulatory advice.
Sources: Microsoft Security Response Center — CVE-2026-69836 · The Hacker News · Help Net Security · CERT-FR CERTFR-2026-AVI-1074 · CIRCL Vulnerability-Lookup · CISA Known Exploited Vulnerabilities Catalog · Microsoft Entra data retention
The initial exploitation claim originated with Microsoft's own advisory and was withdrawn by Microsoft; we found no third-party evidence of exploitation. The KEV addition and subsequent removal are stated on the basis of our own comparison of the 21 August catalogue data against the 31 August 2026 KEV release; we have not seen a CISA statement explaining the removal.