Mitigation and Remediation

ADFS infrastructure should be treated as Tier 0 identity infrastructure, equivalent in criticality to Domain Controllers. If SYSTEM access is achieved on an ADFS host, the signing key must be considered compromised. Hardware-Backed Key Protection: Migrate token-signing certificates to a Hardware Security Module (HSM). HSM-backed keys ensure private key material does not exist in software-accessible storage on the host, eliminating the Machine DPAPI extraction path entirely. gMSA Service Identity: Run ADFS services using Group Managed Service Accounts to automate credential rotation and reduce operational drift in service identity management.

While this does not directly address machine-scoped key protection, it eliminates manual credential management as a contributing factor to configuration drift. Tier 0 Administrative Controls: Govern ADFS servers with strict Tier 0 controls: restricted administrative access pathways, dedicated Privileged Access Workstations (PAWs), separation from general server administration domains, and enhanced privileged access monitoring. Certificate Rotation and Configuration Validation: If compromise is suspected, rotate the token-signing certificate and validate consistency across ADFS configuration, the LocalMachine\My store, and federation metadata. Do not rely on a single source of truth. For environments with AutoCertificateRollover disabled, manual rotation must include updating ADFS via Set-AdfsCertificate—installing the certificate alone is insufficient.

Validate using Get-AdfsCertificate after rotation. If Event ID 385 appears afterward, investigate for configuration inconsistency. Multicloud Scope Awareness: A compromised ADFS token-signing key affects all SAML relying party trusts, not just Microsoft services. Organizations using ADFS for identity federation across other software-as-a-service (SaaS) platforms should treat ADFS as Tier 0 infrastructure and audit all relying party trusts.