The vulnerability was real. The attack was not.

One word in Microsoft's revision note caught my eye: "informational."

The underlying change was anything but routine. Microsoft had published CVE-2026–69836 as an exploited vulnerability in Entra ID. A day later, it changed Exploited: Yes to Exploited: No and stated that the vulnerability "was not exploited in the wild." [2] 2CISA added the CVE to its Known Exploited Vulnerabilities catalog, then removed it about 64 minutes later. [3, 4]

That reversal changed the operational meaning of the disclosure. A confirmed attack can trigger executive escalation, mandatory deadlines, emergency hunting, customer notices, and regulatory review. A severe flaw that was found internally, fixed by the provider, and never exploited calls for a different response.

The flaw itself deserves attention. CVE-2026–69836 was an unsafe-deserialization issue in Microsoft Entra ID. Microsoft scored it CVSS 10.0: network reachable, low complexity, no privileges, and no user interaction. In theory, successful exploitation could lead to remote code execution.

Entra is also no ordinary application. It decides who can sign in, which applications can request tokens, what service principals can do, and when Conditional Access should intervene. Microsoft 365, Azure resources, cloud applications, devices, users, and machine identities all depend on those decisions. A vulnerability in that control plane carries serious potential impact even when no attack took place.

The public record, however, contains no vulnerable endpoint, exploit chain, proof of concept, affected service window, tenant count, threat actor, or indicators of compromise. Microsoft says it found the issue internally, fixed the hosted service, and disclosed the CVE for transparency.

Microsoft appears to have remediated the software before the public heard about it. The disclosure process created a second problem after the code was already fixed.

The good: Microsoft disclosed a flaw it had already fixed

Microsoft could have corrected the service quietly. Customers had no package to install and no configuration to change. Instead, the company assigned a CVE and published a machine-readable advisory.

That was the right call. Cloud providers control the vulnerable code, the deployment process, and much of the telemetry. Without a public record, customers would have no durable way to understand the risk or ask informed questions.

The advisory also kept its revision history. Microsoft's correction is direct. CISA's official GitHub mirror shows both the KEV addition and the later removal. Anyone examining the source material can reconstruct what happened.

There is another point in Microsoft's favor. The company did not respond to the confusion by downgrading the technical severity. CVSS 10.0 describes what the flaw could permit under the scoring assumptions. Exploit status answers a separate question: did anyone use it in the wild? Keeping those fields separate is technically honest.

The provider-side remediation also fits the delivery model. Entra ID is a hosted service. Microsoft owns the code and deploys the fix. "No customer patch required" can be perfectly accurate even for a maximum-severity vulnerability.

The bad: the correction fixed a field, not the uncertainty

Calling the reversal an "informational change" understates what changed.

Security teams do not read Exploited: Yes as trivia. Some organizations automatically escalate any CVE that enters KEV. Tickets are created. Due dates are assigned. Executives are briefed. Analysts begin searching logs. A federal supplier may have policy language tied directly to KEV status.

Changing that value to No can reverse all of those decisions.

The updated advisory answers the headline question, but it leaves the supporting questions open. Why did the original record say the vulnerability was exploited? What evidence led Microsoft to reverse that conclusion? When did Microsoft deploy the fix? Which service rings or components were affected? Could Microsoft determine tenant exposure? What evidence supports its confidence that exploitation did not occur?

Some of those details may be sensitive. I would not expect Microsoft to publish a working exploit path or disclose internal architecture that would create fresh risk. Still, there is room between publishing everything and publishing almost nothing.

A provider can disclose the vulnerable period without naming the endpoint. It can describe how it assessed tenant impact without exposing detection logic. It can tell customers whether relevant evidence exists in tenant-visible logs. It can offer a tenant-specific attestation through authenticated service-health channels.

"No customer action required" answers the patching question. It does not settle the assurance question.

The ugly: security tooling has no dependable undo button

The short-lived KEV entry is the clearest evidence of a larger problem.

Security systems are good at ingesting new alerts. They are far less reliable at retracting them. When a CVE enters KEV, downstream products create state: a ticket, a compliance deadline, a dashboard flag, an email, a threat brief, perhaps an executive slide. Removing the CVE from the source feed does not guarantee that any of those artifacts will be recalled.

I watched the old claim continue to circulate after Microsoft changed its advisory. Some news coverage stayed unchanged. Social posts repeated the initial headline. Automated repositories and vulnerability pages copied the exploited label. At least one supposed exploit repository turned into a monetized lure.

This is how bad metadata becomes operational. It does not need to execute on a server. It executes through the systems and people that trust the feed.

The pattern is familiar outside cybersecurity. A bank can reverse a transaction. A certificate authority can revoke a certificate. A software repository can withdraw a release. Threat intelligence still lacks a consistently honored recall mechanism.

A revision timestamp is useful for an analyst who checks the source manually. Most security operations do not work that way. Automation needs an explicit event that says: this assertion has been withdrawn; remove the derived deadline; close or reclassify the ticket; preserve the old state for audit; notify everyone who received the first alert.

Right now, the first claim often travels farther than the correction.

What customers should do now

Microsoft says it has fixed the hosted service. No public evidence supports a tenant-wide password reset, mass token revocation, or broad certificate rotation.

A measured assurance review is still reasonable because Entra sits at the center of identity and authorization. I would focus on a few concrete actions:

• Correct internal records to show Exploited: No, and keep the earlier value in the audit trail.
• Remove any KEV-derived remediation deadline with a note linking to the withdrawal.
• Preserve available Entra audit and sign-in data before normal retention removes it.
• Review privileged role changes, unusual PIM activations, new application owners, service-principal credentials, OAuth consent, federation changes, authentication-method changes, and Conditional Access modifications.
• Check service-principal and managed-identity activity for unusual resources, source addresses, token behavior, or Graph API use.
• Ask Microsoft for the fix-deployment window, the basis for the no-exploitation conclusion, and tenant-specific assurance when the organization's risk warrants it.

These checks look for downstream identity changes. They cannot detect the unsafe-deserialization flaw itself. That distinction should appear in every hunting recommendation attached to this CVE.

MFA, least privilege, Conditional Access, PIM, and certificate-based authentication remain useful. None of them repairs unauthenticated code execution inside Microsoft's service. Their value is containment: they can limit what a stolen identity, token, or workload credential can do if a compromise ever crosses that boundary.

Where an SBOM helps, and where it stops

This incident is a useful test of how people talk about software bills of materials.

An SBOM is an inventory. It identifies the components and dependencies inside a software build. If the deserialization flaw came from a specific library or shared service component, an internal SBOM could help Microsoft answer important questions quickly:

• Which Entra builds contain the affected component?
• Where else does that component appear?
• Which deployment rings received those builds?
• Did the repaired version reach every production instance?
• Does another Microsoft service depend on the same vulnerable package?

That is useful remediation work. It shortens the distance between finding a vulnerable component and locating every place it must be fixed.

No public advisory identifies the affected component, and customers do not receive an SBOM for Microsoft's internal Entra service. In this case, a customer-side SBOM could not have found or patched the flaw. Even Microsoft's internal SBOM would answer only part of the problem.

An SBOM tells you what may be present. It does not tell you what ran, what was reachable, who touched it, or whether the fix reached the entire fleet.

This is why SBOM programs need several companion capabilities:

VEX or an equivalent status assertion. A Vulnerability Exploitability eXchange statement can say whether a known vulnerability affects a product, has been fixed, or is not reachable under defined conditions. For a hosted service, the provider needs a service-level status assertion tied to actual builds and deployment rings.

Signed build provenance. Teams need evidence connecting source code, dependencies, build output, and the artifact deployed to production. An SBOM that cannot be tied to a deployed artifact is only a list.

Runtime reachability and telemetry. Static inventory cannot show whether a vulnerable code path was exposed or executed. Application telemetry and control-plane logs fill that gap.

A service dependency map. SaaS platforms change continuously. Providers need a current view of shared libraries, internal services, APIs, deployment rings, and tenant boundaries. Traditional SBOM files rarely capture the full operating context.

Deployment and tenant-impact attestations. Customers need to know when the fix reached the provider's fleet and whether their tenant was exposed during the vulnerable period. That information may not require publishing the provider's entire internal SBOM.

An identity inventory. Entra governs human and machine identities. Knowing which service principals, workload credentials, application grants, certificates, and privileged roles exist is essential for containment if suspicious activity appears.

The European Union's Cyber Resilience Act points in this direction for covered products with digital elements. Its vulnerability-handling requirements call for a machine-readable SBOM covering at least top-level dependencies. 6That requirement improves component accountability. It does not remove the need for reachability, evidence, and disclosure discipline.

Disclosure needs the same lifecycle controls as software

The security industry already has most of the technical pieces. CSAF supports machine-readable advisories. VEX can express vulnerability status. Digital signatures can authenticate the publisher and protect integrity. Event-driven systems can carry revisions and withdrawals.

The missing part is a disclosure contract that providers, government feeds, publishers, and security vendors agree to honor.

For a cloud vulnerability of this importance, I would expect the public record to separate technical severity, exploit status, service-fix status, customer impact, and customer action. Each field should carry its own timestamp, source, and confidence.

When a material field changes, the revision should explain why. The provider should publish the affected service window or explain why it cannot. Customers should receive useful evidence: logs, indicators, detection guidance, or a tenant-specific attestation. A machine-readable withdrawal should travel through the same channels as the original alert.

The correction also deserves equal distribution. If the first advisory can trigger an email, a KEV addition, and an emergency ticket, its withdrawal should be able to trigger an email, a KEV removal, and a ticket reclassification.

NIST's guidance for vulnerability advisories already includes affected products, impact, severity, remediation, dates, and revision history. 7This episode shows the missing requirement: downstream consumers must treat those revisions as operational events rather than footnotes.

A short US and EU comparison

The United States has no single federal law requiring every software provider to disclose every vulnerability publicly. The rules depend on the organization, sector, contract, and event. Public companies must file a Form 8-K within four business days after determining that a cybersecurity incident is material. 8 That SEC rule concerns material incidents, not every severe CVE. CISA requires federal civilian agencies to maintain vulnerability disclosure policies, but that directive does not create a general private-sector product-disclosure deadline.

The European Union's Cyber Resilience Act uses a product-lifecycle model. Starting September 11, 2026, manufacturers of covered products with digital elements must report actively exploited vulnerabilities and severe security incidents through the CRA Single Reporting Platform. The deadlines are 24 hours for an early warning, 72 hours for the full notification, and no later than 14 days after a corrective measure becomes available for the final vulnerability report. 9

CRA does not require reporting every CVSS 10 flaw. The Article 14 trigger is active exploitation. Standalone SaaS is not automatically covered simply because it runs in the cloud. Cloud functionality can fall within CRA when it is necessary for a covered product to perform one of its functions. Other EU rules, including NIS2, generally govern standalone cloud services.

For that reason, I would not present this Entra disclosure as an obvious CRA Article 14 case. The comparison is still useful. The US approach is mostly materiality and sector driven. CRA gives covered product manufacturers a statutory clock and lifecycle duties, including component documentation and vulnerability handling.

This regulatory summary is general information, not legal advice.

What I would change

Microsoft fixed the software. The next fix belongs to the disclosure process.

Any field capable of triggering mandatory or emergency action must support an authenticated withdrawal that can undo that action downstream.

Then I would ask cloud providers for three pieces of evidence after a critical hosted-service flaw: the vulnerable service window, confirmation that the fix reached the full fleet, and a tenant-impact statement that customers can verify or request through an authenticated channel.

An SBOM can help the provider find the affected component. It cannot carry the whole burden. Customers also need provenance, reachability, runtime evidence, deployment assurance, and a reliable correction process.

CVSS told us this flaw could have been severe. Microsoft's revision told us it was not an observed attack. The 64-minute KEV reversal showed that our disclosure machinery can publish a conclusion faster than it can establish, explain, or retract one.

That is the part I would not dismiss as informational.

About the Author

Tim McAllister_ is a Regional Field CTO in DigiCert's Office of the CTO. He works with enterprises and original equipment manufacturers on digital trust, PKI, device identity, software signing, Cyber Resilience Act readiness, and post-quantum migration-particularly where a policy requirement becomes an engineering and operating problem._

Tim contributes to standards and industry initiatives involving NIST, SAE EVPKI, Matter, and CharIN. He writes about the practical use of digital trust and trusted AI, including the controls, ownership models, and market decisions required to move from technical guidance to defensible operation.

Tim writes here in his personal capacity. The views expressed are his own.

Notes and sources

1. Image source: OpenAI GPT Image 2.0, generated August 22, 2026 for this article. This is editorial artwork, not an official Microsoft graphic. The original PNG contains a signed OpenAI C2PA Content Credential; OpenAI documents that supported GPT Image outputs also include an invisible SynthID watermark. EU reference: Regulation (EU) 2024/1689, Article 50(2) requires providers of in-scope generative AI systems to mark synthetic outputs in a machine-readable format and make them detectable; Article 50(4) separately requires deployers to disclose qualifying deepfakes. Article 50 applies from August 2, 2026. A caption or provenance mechanism does not alone determine legal applicability or compliance. Sources: OpenAI, "C2PA in ChatGPT Images," help.openai.com; EUR-Lex, eur-lex.europa.eu; European Commission, "Guidelines on transparency obligations for providers and deployers of AI systems," digital-strategy.ec.europa.eu.
2. Microsoft Security Response Center, "CVE-2026–69836: Deserialization of Untrusted Data in Microsoft Entra ID," revision 1.1, August 21, 2026. Source: msrc.microsoft.com.
3. Cybersecurity and Infrastructure Security Agency, official KEV data mirror, commit 935d1ecbfff6eaf27c441307fd016d4e1ac78853, showing CVE-2026-69836 present in the catalog. Source: github.com/cisagov/kev-data.
4. Cybersecurity and Infrastructure Security Agency, official KEV data mirror, commit e7ad2b019b39b438c2a906fb86c7a7208e680d3f, showing CVE-2026-69836 removed from the catalog. Source: github.com/cisagov/kev-data.
5. Image source: OpenAI GPT Image 2.0, generated August 22, 2026 for this article from the Microsoft and CISA records cited above. The original PNG contains a signed OpenAI C2PA Content Credential; OpenAI documents that supported GPT Image outputs also include an invisible SynthID watermark. EU reference: Regulation (EU) 2024/1689, Article 50(2) requires providers of in-scope generative AI systems to mark synthetic outputs in a machine-readable format and make them detectable; Article 50(4) separately requires deployers to disclose qualifying deepfakes. Article 50 applies from August 2, 2026. A caption or provenance mechanism does not alone determine legal applicability or compliance. Sources: OpenAI, "C2PA in ChatGPT Images," help.openai.com; EUR-Lex, eur-lex.europa.eu; European Commission, "Guidelines on transparency obligations for providers and deployers of AI systems," digital-strategy.ec.europa.eu.
6. Regulation (EU) 2024/2847, Annex I, Part II, requiring manufacturers of covered products to maintain a machine-readable SBOM covering at least top-level dependencies. Source: EUR-Lex, eur-lex.europa.eu.
7. National Institute of Standards and Technology, "Software Security in Supply Chains: Vulnerability Management," including recommended vulnerability-advisory elements and machine-readable VEX. Source: nist.gov.
8. U.S. Securities and Exchange Commission, "Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure," Form 8-K Item 1.05 guidance. Source: sec.gov.
9. European Commission, "Cyber Resilience Act: Reporting obligations," updated July 31, 2026. Source: digital-strategy.ec.europa.eu.

Originally published at https://timmcallister.substack.com on August 23, 2026.