Is CVE-2026-56155 (Microsoft Active Directory Federation Services Insufficient Granularity of Access Control Vulnerability) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2026-56155 to its Known Exploited Vulnerabilities catalogue on 14 July 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft Active Directory Federation Services contains an insufficient granularity of access control vulnerability that allows an authorized attacker to elevate privileges locally.

Why this counts as active exploitation, not just a published CVE

CISA’s KEV catalogue is the practical threshold here: it is a curated list of vulnerabilities with credible evidence of exploitation, so inclusion is a strong signal that defenders should treat the issue as live. For prioritisation, pair the KEV signal with vendor guidance and any internal exposure to Active Directory Federation Services rather than waiting for secondary reporting.

The key operational question is whether your AD FS estate is reachable, in use, and exposed to the vulnerable access-control path. If the service is internet-facing, federates critical applications, or sits on a high-trust identity boundary, the risk is materially higher because privilege changes in federation infrastructure can cascade across many dependent systems.

For background on how to triage actively exploited issues, see Zero-Day and Exploited Vulnerabilities Guide.

What the vulnerability means for federation security

An insufficient granularity of access control flaw means the authorization boundary is too coarse for the privilege decisions the system is making. In AD FS, that matters because federation components often sit close to authentication, token issuance, claims processing, and administrative functions, so a local privilege increase can become a control-plane problem rather than a single-server issue.

That distinction is important: the weakness is not simply “someone can log in”, but that an authorized attacker may be able to do more than intended once they are already on the host. In practice, that can expand the blast radius from one compromised foothold to broader identity infrastructure access, especially if the server is over-privileged or poorly segmented.

For a deeper view of the access-control patterns that shape this kind of risk, see Authorisation Models Guide.

How to confirm exposure and decide what to do next

Start by confirming whether you actually run Microsoft Active Directory Federation Services, where it is deployed, and who can reach it. Then verify whether the affected host is part of a federation path that supports production sign-in, partner trust, or privileged administration, because those roles determine whether exploitation would be contained or broadly consequential.

If patching or mitigation cannot happen immediately, treat the server as a high-value identity asset: restrict administrative access, isolate management paths, review local and domain privilege assignments, and watch for unusual service restarts, configuration changes, or new admin activity on the host. You should also preserve logs for later compromise review, because exploitation of a privilege-control flaw can be subtle after the fact.

For the broader identity-side checks that matter around federation and privilege boundaries, see Active Directory and Entra ID Hardening Guide and Top 10 Active Directory Security Risks.

Risk and Threat Considerations

Because AD FS commonly bridges authentication across business-critical applications, a privilege-escalation flaw in that layer can expose more than the host itself. The main risk is not just local compromise, but trust abuse: once the federation tier is weakened, an attacker may be able to move toward token handling, administrative control, or downstream identity abuse.

Failure mechanism: An attacker with authorized local access can exploit the access-control granularity weakness to gain higher privileges than intended, then use that elevated position to alter federation settings, access protected material, or prepare further movement into connected identity services.

Impact: The likely impact is expanded administrative reach over a high-trust identity component, which can enable broader compromise, persistence, or disruption across applications that depend on AD FS for sign-in and trust decisions.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	AD FS privilege escalation maps to limiting excessive local and delegated rights.
	IA-5 — Authenticator Management	Federation servers rely on secrets and authenticators that can be exposed or abused during compromise.
	AU-6 — Audit Record Review, Analysis, and Reporting	Exploitation review depends on logs that can show privilege changes and abnormal AD FS activity.
Recommendation — Restrict AD FS administrative rights to the minimum necessary. Rotate and protect federation credentials and signing material promptly. Review AD FS and host logs for abnormal privilege use and configuration changes.
CIS Controls v8	CIS-5 — Account Management	Account and privilege control is central to limiting abuse of an AD FS privilege flaw.
Recommendation — Tighten privileged account management around AD FS administrators and service accounts.
MITRE ATT&CK	T1068 — Exploitation for Privilege Escalation	The issue is an access-control weakness used to elevate privileges locally.
Recommendation — Map observed AD FS abuse to privilege-escalation detection and response.

Practitioner Guidance

What to prioritise: Treat the AD FS server as part of the identity control plane, not as a routine application host. Prioritise exposure review, privilege review, and containment before general hardening work, because the business impact comes from where the system sits in the trust chain.

What to verify: Confirm the exact federation role, who has local administrative access, whether any service accounts or delegated admins can reach the box, and whether monitoring can distinguish normal federation operations from unexpected privilege changes.

Decision rule: If the server participates in production federation or privileged sign-in flows, do not wait for a second confirmation source to start response actions. Use the KEV listing as a trigger to accelerate patching or compensating controls, then perform targeted compromise review once containment is in place.

Practitioner takeaway: For a KEV-listed federation flaw, the right unit of response is the trust boundary, not just the host, because privilege escalation in identity infrastructure can have disproportionately wide downstream effects.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org