Your Identity Provider Needs a Containment Boundary

Identity is often described as the new perimeter. That framing misses the harder architectural question: what protects the system that creates the identity assertion?

New Mandiant research makes the problem concrete. During a red team engagement, Mandiant recovered an active Active Directory Federation Services token-signing key from the host’s machine-scoped cryptographic store. With that key, the team forged a SAML assertion for a Global Administrator identity that Microsoft Entra ID accepted.

No user password was required. No MFA challenge had to be defeated. The forged assertion was signed by a key the relying service already trusted.

This is not an argument against identity controls. It is an argument for treating identity infrastructure as critical infrastructure, and for designing a containment boundary around it before an attacker gets SYSTEM access.

The Trust Root Is Also An Attack Path

In the scenario documented by Mandiant, the AD FS environment had AutoCertificateRollover disabled and used manual certificate rotation. The Windows Internal Database still referenced an expired certificate, while the active signing key lived in the machine certificate store. That configuration drift created a misleading picture of where the usable key was stored.

The active private key was protected through Machine DPAPI. Mandiant explains that a sufficiently privileged local process can recover the required machine key material without interacting directly with LSASS memory or the live AD FS service process. That matters because defensive coverage focused narrowly on conventional credential dumping may miss the path.

The architectural consequence is bigger than the extraction technique. A stolen token-signing key can be used to create valid-looking identity assertions for SAML-federated applications. Mandiant explicitly warns that the scope includes Microsoft 365, Entra ID, and other SaaS relying parties connected to AD FS.

The federation server is therefore not just another Windows server. It is a trust issuer. Compromise of the issuer can undermine the identity decisions made downstream.

Microsoft’s own AD FS placement guidance says federation servers should receive the same protection as domain controllers because they can grant security tokens. Mandiant reaches the same operational conclusion: treat AD FS as Tier 0, and treat the signing key as compromised if an attacker achieves SYSTEM access on the host.

Where Microsegmentation Fits

Microsegmentation cannot make a stolen signing key harmless. It cannot validate the intent behind a correctly signed SAML assertion, and it does not replace HSM-backed key protection, certificate hygiene, endpoint detection, or identity telemetry.

It can reduce the ways an attacker reaches the federation server and the systems required to operate it.

That starts with an explicit dependency map. An AD FS farm may need paths to domain controllers, Web Application Proxy servers, load balancers, certificate infrastructure, monitoring systems, patching services, administrative workstations, and selected management tooling. Those dependencies should be observed and documented, not inferred from a broad server subnet.

Then the containment boundary can be made concrete:

Only approved Web Application Proxy systems and required load balancer health checks should reach the federation service paths.
Administrative protocols should be reachable only from hardened privileged access workstations or a dedicated management plane.
Federation servers should not accept management traffic from general user networks, ordinary server estates, or shared automation runners.
East-west communication between federation nodes should be limited to the exact farm members and required ports.
Outbound access should be restricted to documented operational dependencies rather than open Internet access.
Security telemetry and backup paths should be one-way or narrowly scoped wherever the architecture allows it.

Microsoft’s AD FS hardening guidance supports this direction. It recommends limiting on-network access with host firewalls, restricting administrative rights, using dedicated administrative workstations, protecting signing keys with an HSM, and ensuring that only federation farm and proxy systems can use the required inter-server communication.

The important distinction is that the boundary should follow the workload and its dependencies, not merely a VLAN label. A Tier 0 subnet with broad internal reachability is still broad reachability.

Containment Must Include The Management Plane

Many segmentation projects start with application tiers and postpone management traffic. For identity infrastructure, that order is dangerous.

The management path is the path to the signing key. Remote administration, software deployment, monitoring agents, backup tools, security agents, group policy, and certificate operations all create privileged relationships with the host. If one shared platform can administer both ordinary workloads and Tier 0 identity systems, compromise of that platform can collapse the boundary.

This is why identity isolation cannot be reduced to blocking user subnets from AD FS. The policy model has to answer harder questions:

Which systems can execute code on the federation server?
Which identities can change its configuration or certificate state?
Which services can read, back up, or export cryptographic material?
Which automation platforms can deploy to the host?
Which network paths would still exist after a management system was compromised?

These are reachability questions and privilege questions at the same time. Mature Zero Trust architecture needs both views. NIST SP 800-207 is clear that network location must not create implicit trust. For a federation server, that means neither “internal” nor “Tier 0 network” is enough. Every administrative and service path needs a reason, an identity, and an enforceable scope.

Build The Incident Plan Around Key Compromise

If SYSTEM access is confirmed on an AD FS host, rebuilding the server without rotating trust material is not containment.

Mandiant recommends considering the signing key compromised, rotating the token-signing certificate, validating consistency across AD FS configuration, the local machine certificate store, and federation metadata, and reviewing every relying-party trust. In environments with manual rollover, installing a new certificate alone is insufficient. The active AD FS configuration must also be updated and verified.

The network response should happen in parallel:

Isolate the affected federation node while preserving required evidence.
Restrict remaining farm members to known-good proxies, management systems, and dependencies.
Hunt the systems that had administrative or deployment reachability to the affected host.
Review whether the same management plane can reach domain controllers, certificate authorities, Entra Connect, or other identity infrastructure.
Monitor federated applications for assertions that do not correlate with expected primary authentication events.

The last point matters because a forged assertion may look valid to the application. Mandiant recommends correlating AD FS token issuance with primary authentication context and monitoring access to the machine cryptographic stores. Detection has to cover both the host and the identity plane.

The Practical Standard

An identity provider should be designed like a system whose compromise can mint trust, because that is exactly what it does.

The practical standard is not “put AD FS behind a firewall.” It is:

protect the signing key with hardware-backed controls where possible;
remove unnecessary administrative and service paths;
isolate the federation workload from general server and user estates;
separate Tier 0 management from shared operational tooling;
validate certificate state across every relevant source of truth;
prepare to rotate trust, not just rebuild a host.

MFA remains essential for users and administrators. But MFA cannot save an environment from a trusted signing key in an attacker’s hands.

That is why identity needs containment, too.

Sources

This article was generated with the assistance of AI and reviewed by the author.

microsegment.io