AD FS Machine DPAPI: The Active Signing Key Beyond an Expired Database Record

1 A certificate that could be decrypted but could no longer mint trust

The first result looked almost conclusive. An encrypted object came out of the Windows Internal Database, Distributed Key Manager material from Active Directory decrypted it, and the recovered certificate could be used to produce a structurally valid SAML assertion. The XML was not obviously broken and the signature operation completed. The last hop overturned the apparent success: Microsoft Entra ID returned AADSTS500172 and rejected the assertion because the signing material was no longer trusted.

That rejection did not prove the active AD FS key was safe, and it did not make the database recovery technique wrong. It established a narrower fact: the certificate returned by that database path was no longer the certificate accepted by the downstream federation trust. Mandiant reported that AutoCertificateRollover had been disabled in the assessed environment, an administrator had performed a manual rotation, and WID still retained an expired record. The database had preserved history, not the whole of current runtime state.

Stopping there would have produced a dangerous false negative. AD FS was still issuing tokens, so some usable signing capability had to exist on the federation server. The question therefore changed from “Why did the recovered certificate fail?” to “Which private key does the service actually open when it signs now?” That shift—from an expected storage location to an observed runtime outcome—is the hinge on which the rest of the investigation turns.

Mandiant found a matching RSA private key in the machine-scoped CAPI storage of that server. Machine DPAPI protected it through the host's DPAPI_SYSTEM secret and SYSTEM machine master-key material; the stale WID certificate record did not participate in the active protection chain. In the authorized assessment, the active key signed an assertion representing a Global Administrator, and Entra accepted it. That result validated impact in the assessed environment; it did not claim that an unknown attacker had performed the same action elsewhere.

Four observations must remain connected: WID and DKM successfully recovered an old certificate; the downstream trust rejected a signature made with it; the Windows cryptographic store contained the active private key; and an assertion signed with that active key was accepted. Any one observation can mislead when quoted alone. Together they show that database configuration, host key custody, AD FS runtime selection, and relying-party acceptance had become different, partially unsynchronized planes of truth.

1.1 Four truth planes answer four different questions

Get-AdfsCertificate reports what AD FS configuration considers Primary and Secondary. The local LocalMachine\My store and its provider reveal whether a particular node can actually open the associated private key. Federation metadata shows which public certificates the service is publishing. A relying party's own cache or manually managed trust answers what that application will accept at this moment. WID contributes evidence to the first question, but it cannot silently stand in for all four.

Certificate subject, validity dates, and thumbprint are not interchangeable identifiers. A familiar subject can be reused across renewals; an expiration date says when the object ceases to be valid; the thumbprint fixes one certificate object. Private-key presence, exportability, provider, container, access control, and hardware backing are another set of properties. A useful ledger keeps those fields beside one another instead of collapsing them into a green status label that says only “AD FS certificate healthy.”

A farm multiplies the possible disagreement. Configuration may be shared while local stores, provider registrations, private-key ACLs, and service access differ by node. One server can sign correctly while another fails intermittently behind the load balancer. Metadata can look correct even when a node cannot open the new private key. A single console screenshot or a single successful sign-in proves only the path that produced it, not the health of the entire farm.

Relying parties add their own clocks. Some fetch metadata automatically, some require an administrator to import a certificate, and some deliberately trust old and new public keys during an overlap. Rotation is not complete merely because AD FS displays a new Primary. Completion requires evidence from real consumers: the thumbprint they hold, the time they refreshed it, a successful sign-in with the new signature, and—after the approved overlap—their rejection of the old signature.

The smallest reliable reconciliation key is a combination of thumbprint, purpose, node, and collection time. Subject alone collapses distinct renewals; thumbprint alone omits whether the object was Primary, Secondary, or retired at the relevant moment. State must be recorded as a timeline. That is how an investigator distinguishes a clean historical artifact from a certificate that remained accepted longer than intended.

Missing evidence belongs in the ledger too. A node whose provider cannot be queried, an abandoned application with no owner, a rotated AD FS audit log, or a third party that cannot expose its trusted thumbprint is not an empty cell meaning “consistent.” It is an unknown that lowers confidence and may change the recovery decision. In a high-impact federation incident, acknowledged uncertainty is operationally safer than an invented match.

A recent rotation is an explanation to test, not a verdict. It becomes persuasive only when the approver, change window, certificate identities, metadata publication, consumer uptake, promotion, and retirement evidence agree. Even then, it does not explain unrelated sensitive reads in the same interval or prove that every consumer removed the old trust.

Disagreement among the four planes is not, by itself, proof of intrusion. Replication delay, maintenance, stale caches, or an omitted manual step can all create temporary divergence. The situation changes when that divergence aligns with an unexplained privileged session, access to sensitive key material, an issuance gap, or consequential downstream activity.

The first-pass deliverable should therefore be a difference table, not a conclusion. For each plane, record the expected and observed thumbprint, the earliest known divergence, plausible causes, supporting and contrary evidence, the responsible owner, and the next validation. The table keeps the investigation moving while preventing an attractive explanation from becoming fact too early.

1.2 The public evidence is strong precisely because its limits are visible

Mandiant described an authorized red-team assessment. Its report explicitly supports the following environmental observations: automatic rollover was disabled; WID returned expired signing material; the attempted User DPAPI recovery did not yield usable AD FS service-account material in that environment; the Machine DPAPI path produced the active CAPI key; and a controlled assertion signed with that key was accepted. It did not claim that every AD FS deployment uses CAPI or that every User DPAPI path must fail.

The same discipline applies to the pinned SharpDPAPI source. The implementation helps confirm relationships among CAPI and CNG formats, LSA secrets, machine master keys, certificate matching, and key containers. Its support for those structures does not prove that a real intruder used that project, nor does it reveal the commands executed during Mandiant's assessment. Source review explains how objects can connect; it is not an incident indicator and should not be narrated as one.

A fixed source snapshot can validate object relationships, algorithm branches, and supported formats; it cannot reconstruct an unreported command line, login path, or duration. If the assessment did not publish those event details, the report must leave them unknown instead of manufacturing a plausible sequence around the code.

Event ID 385 was a valuable drift symptom in the assessed environment, but it is not a private-key-theft event. Legitimate manual rollover mistakes, incomplete synchronization, and certificate lifecycle failures can produce comparable configuration symptoms. Its correct role is to open a time-bound integrity investigation: reconcile all four planes, identify the responsible change, and then correlate host access, token issuance, and downstream identity outcomes.

A careful report therefore uses four voices. “Observed” is reserved for what the public assessment recorded. “Vendor-defined” describes product behavior documented by Microsoft. “Analysis” covers a defensible consequence derived from those sources. “Unknown” remains attached to details the sources do not provide, such as an unreported victim population, an attacker's identity, or a minute-by-minute intrusion sequence. Severity never grants permission to convert an inference into an observation.

This matters most in the impact paragraph. The assessment demonstrated that the recovered active key could sign a high-privilege assertion that Entra accepted. That proves capability and validates the control failure in the authorized environment. It does not prove that a production tenant was secretly administered by an external actor. Readers can understand the worst credible consequence without being told that the consequence already occurred.

Negative results deserve the same precision. The unsuccessful User DPAPI avenue narrowed the hypothesis space and helped redirect the work toward Machine DPAPI; it did not establish a universal Windows law. A negative finding is reusable only when the tested scope, account type, provider, operating-system context, and available artifacts remain attached. Otherwise it becomes a brittle detection assumption that a different deployment will break.

The resulting public conclusion is narrow but consequential. If AD FS configuration and host runtime have diverged, a database extraction may recover only historical signing material. If an attacker has obtained sufficient privilege on a federation server and the active key exists as exportable, machine-scoped software material, changing the service-account password and checking WID are not enough to exclude signing-key compromise. The evidence supports that conclusion without proving anything broader.

2 Manual rollover split one key lifecycle into two timelines

Automatic certificate rollover is a staged sequence, not a single replacement. A new signing certificate appears as Secondary, enters federation metadata before it is needed, and gives relying parties time to refresh. At the promotion threshold it becomes Primary, while the old certificate remains for a defined overlap before retirement. The waiting periods are how distributed trust changes without an avoidable outage.

Disabling AutoCertificateRollover means the organization has accepted responsibility for that entire state machine. Administrators must create or import the new certificate, ensure every farm node can use its private key, register it with AD FS, publish the public key, confirm consumer uptake, promote it, and remove the old trust. Replacing that sequence with “the certificate is installed in Windows” leaves several security states unmeasured.

The “ghost” in this case was the residue of that split. WID could still expose and decrypt an old object, while the running service continued with another key from the operating-system cryptographic store. The historical recovery method faithfully returned what the database contained. It failed only when its result was treated as an answer to a different question: which private key was actually deciding trust now?

Drift also changes what defenders need to watch. Monitoring only WID or DKM access can miss a read of the active machine key. Watching only memory access to lsass.exe can miss an offline combination of registry hives, LSA secrets, master-key files, and a cryptographic container. Normal service access and suspicious recovery both intersect the operating-system key layer, so object, process, logon context, and subsequent identity outcome must be evaluated together.

2.1 WID and DKM still matter, but as time-bound evidence

The database path remains valuable. It can preserve farm configuration, certificate records, and encrypted objects, while DKM provides domain-held material used to protect related secrets. Investigators can reconstruct earlier certificates, compare role changes, and explain why a signature was accepted during one period but rejected later. Calling the path “obsolete” because it returned an expired key would discard exactly the history needed to understand the drift.

Every recovered object needs a timestamp and a role. Record the backup or snapshot time, thumbprint, NotBefore, NotAfter, Primary or Secondary state, configuration-change events, and the consumer trust window. Then compare those facts with the node store, metadata, and observed sign-ins from the same interval. A key can prove historical signing capacity without saying anything about today's capacity.

That comparison is only as good as its clocks. Record synchronization health for AD FS nodes, domain controllers, proxies, Entra, and major third parties; normalize analysis to UTC while preserving each source's original time zone. Skew affects certificate validity, assertion windows, and log joins, so an unexplained minute can be a clock problem before it becomes an identity finding.

AADSTS500172 became useful contrary evidence because it separated a structurally valid assertion from a currently trusted signature. The code does not identify the root cause on its own, but in this assessment it demonstrated that the recovered old object failed the relying party's trust check. A cropped error message loses the join fields, so a production investigation should retain request time, tenant, application, and correlation data.

Historical records can also expose uncontrolled lifecycle management. If WID state, operator logs, change tickets, metadata publication, and consumer refresh dates disagree, the organization lacks a provable certificate history. The disappearance of Event 385 does not repair that history. A closure record must say which plane was corrected, how, by whom, and what independent evidence confirmed the correction.

The database history should answer three accountability questions: why the old object still exists, when AD FS stopped using it, and when every relying party stopped accepting it. A record that answers only the first question may describe retention, but it cannot distinguish an orderly retirement from an incomplete rollover.

It helps to treat rollover as a distributed transaction. New-key generation, per-node usability, Secondary registration, metadata publication, consumer uptake, Primary promotion, and old-trust deletion are separate commit points. At each point the runbook should say what has changed, what remains safe to reverse, and whether a rollback would restore reliance on a potentially exposed key.

That distinction becomes urgent after partial publication. Before metadata changes, rollback may affect only the local farm. Once some relying parties have consumed a new public key, reversing the change can create two incompatible consumer populations. After promotion, discovering that a critical legacy application did not refresh forces an explicit decision among interruption, temporary overlap, and isolation. The decision should exist in the incident record, not be hidden inside an improvised command.

2.2 Confirm the active certificate by tracing backward from real service behavior

Begin with Get-AdfsCertificate, but do not end there. On every farm node, locate the same thumbprint in LocalMachine\My and verify the private-key association, provider, key specification, access control, and service usability. In an HSM deployment, record the provider, device or partition identity, policy, and high-availability path; a software private-key file is no longer the expected evidence object.

Next, retrieve federation metadata and compare its signing-certificate set with the planned state. Metadata is the publication plane; it does not prove consumption. Perform controlled authentication against critical Microsoft and third-party relying parties, then connect the AD FS issuance record, the signature thumbprint in the SAML response, and the downstream sign-in. The end-to-end result is what establishes which key actually minted accepted trust.

The validation matrix must cover every node and every important path. Without a backend identifier, ten successful tests may all have reached one healthy server. During a controlled window, direct traffic by a supported method or use proxy telemetry to identify the selected node. Preserve the AD FS activity identifier and downstream correlation for each row, then restore normal routing and verify health checks.

Fix the matrix scope before testing: every farm node, each critical protocol path, and every high-impact relying party gets a row. Use least-privilege test identities, preserve only correlation identifiers and the signing thumbprint in ordinary records, and keep reusable tokens out of tickets. An untested cell prevents a farm-wide or consumer-wide conclusion.

Load balancing can conceal the exact unhealthy node the matrix is meant to find. Use supported backend targeting or join proxy backend telemetry to the AD FS activity record, then return routing to its normal state and verify service health. Repeated success through an unidentified backend is availability evidence, not per-node signing evidence.

Consumer confirmation should contain technical evidence, not merely a message saying “done.” The strongest record includes the public-key thumbprint currently stored by the relying party, its last metadata refresh, a successful test with the new signature, and—after the agreed overlap—a failed test with the old signature. Where a legacy application cannot supply that evidence, its owner must accept the uncertainty and document the compensating action.

Failure paths belong in the test plan. A Secondary key that a node cannot open should block promotion. Failed metadata publication should alert. A node missing the new key should leave service before it can produce intermittent authentication errors. A consumer rejection should be traceable to a specific key and refresh state. Testing only the happy path allows the same drift to return at the next rotation.

Before a rotation begins, write the expected-state contract: new and old thumbprints, their intended roles, participating nodes, publication time, promotion criteria, consumer batches, maximum overlap, rollback condition, and decision owner. Automation should stop when it encounters an unplanned node, certificate, or consumer state instead of adapting silently around it.

Only then return to WID. Determine whether current objects now match the runtime plan, whether historical objects have an intelligible retirement status, whether automation used supported AD FS management interfaces, and whether the change record contains consumer evidence. The database is again useful—but as one member of a closed evidence loop, no longer as a substitute for observed signing behavior.

3 Machine DPAPI protects machine continuity—and inherits machine compromise

Machine DPAPI exists first to keep services working. A service-account password change, a gMSA rotation, a reboot, or an AD FS restart should not strand the signing key behind an interactive user's profile. Binding protection to the computer lets an authorized local service reopen the same cryptographic object across those events. That operational continuity is useful, expected Windows behavior; it is also why a service password change and a token-signing-key rotation are two different security actions.

Changing the service identity's password does not generate a new RSA key, issue a new certificate, update federation metadata, delete an old public key from relying parties, or invalidate sessions that were already established. A response plan that checks “service credentials rotated” and closes the incident has changed one authentication secret while leaving the federation signing capability in place. The distinction is easy to miss because both objects are colloquially called credentials.

Microsoft's documentation for CRYPTPROTECT_LOCAL_MACHINE describes the computer scope: protected data is associated with the machine and is not exclusive to the calling user's credentials. File ACLs, LSA-protected secrets, master keys, process tokens, and the operating system's own protections still matter. “Machine scope” does not let an arbitrary remote user decrypt the key. Sufficiently privileged compromise of the host can defeat the same protections on which the service depends.

An AD FS server should therefore be treated as identity Tier 0 infrastructure. It may not contain every user's password, yet it holds the capacity to assert identities to every relying party that trusts its issuer and public key. Once SYSTEM integrity is lost, the default investigative question is whether the active signing key or signing capability could have been exposed—not whether an analyst has already found a conveniently named exported key file.

3.1 Offline recovery is a chain of host artifacts, not one certificate file

The pinned SharpDPAPI implementation makes the dependency structure visible. SYSTEM and SECURITY registry hives contribute information needed to derive the boot key and recover LSA-protected secrets. DPAPI_SYSTEM supplies machine and user components used for SYSTEM-scoped DPAPI material. Master-key files under the S-1-5-18 protection directory can then participate in decrypting DPAPI blobs associated with a cryptographic key container. Only after those layers validate can an RSA private key emerge.

The boot key itself is reconstructed from several registry class values in a defined order before the relevant SECURITY policy material can be processed. That sequence is important defensively because it shows why a copied MachineKeys file is not equivalent to a usable signing key. Seeing a container on disk, or even collecting it successfully, proves the existence of an artifact. It does not prove that the required secrets, master key, integrity checks, and certificate relationship are present.

A DPAPI master-key file is identified by a GUID, while a protected blob references the appropriate master-key identity and carries parameters such as salt, iteration count, hashing and encryption algorithms, authentication material, and ciphertext. Implementations vary across versions and formats. An unsupported branch or failed integrity check is a hard stop in the result, not an invitation to assume success. A trustworthy forensic record keeps the error and the tool version.

Collection must preserve provenance across the chain. SYSTEM, SECURITY, the Protect directory, and a key container obtained from different snapshots or different farm nodes cannot silently be treated as one coherent state. The acquisition log should include host, volume, snapshot time, filesystem timestamps, and hashes. If the artifacts cannot be shown to coexist, the analyst may test a hypothesis, but the result cannot describe the original machine with high confidence.

Use a collection ledger for every artifact and transformation: source, time, hash, host, acquisition privilege, analyst, and derived-object relationship. Controlled originals stay in restricted evidence storage; working tables use GUIDs, thumbprints, hashes, and validation status. Ordinary tickets and chat should never become accidental repositories for recovered secrets.

Backup infrastructure creates a second route to those artifacts. A principal who can read a system-state backup may obtain several components without opening an interactive session on the production AD FS node. Backup repositories, recovery consoles, snapshot service accounts, virtualization administrators, and exported media therefore belong in the same privileged-access review. Protecting the live folder while broadly delegating backup reads leaves the underlying reconstruction risk intact.

Online and offline access leave different evidence. A legitimate AD FS process normally reaches a key through the cryptographic provider; an offline chain that combines hives, LSA material, master keys, and a container intersects snapshot, backup, mount, process, and transfer records. Detection should prioritize that unusual combination and context; a favored tool name supplies only supporting detail.

Analysis should use read-only copies in an isolated environment. Values such as DPAPI_SYSTEM, decrypted master keys, or private-key bytes do not belong in chat transcripts, ordinary tickets, shell histories, or analyst desktops. Most verification can be documented with artifact hashes, GUIDs, certificate thumbprints, public parameters, and the result of a controlled signature check. Each avoided plaintext copy removes another incident waiting to happen.

Preserve the scene before proving the hypothesis. Importing a certificate, changing an ACL, loading a profile, starting a provider, or running a signing test on the live farm can alter timestamps, caches, and audit records. Prefer forensic copies; when an online action is unavoidable, record its expected side effects, window, operator, rollback, and research tag so later analysts do not mistake it for hostile activity.

Every successful layer proves only its own statement. DPAPI integrity validation says a blob was correctly decrypted; it does not assign the object to AD FS. A mathematical public/private match assigns it to a certificate; it does not establish that the certificate was Primary at the relevant time. A controlled signature says the key works; it does not prove every production relying party still accepts it. Investigation quality comes from refusing to skip those attribution steps.

3.2 The User DPAPI failure was an environmental observation, not an architectural law

Mandiant first investigated a user-scoped path. A domain DPAPI backup key could recover some master-key material associated with interactive profiles, but it did not produce usable AD FS service-account material in the assessed environment; other offline attempts in that branch were also unsuccessful. The negative result matters because it explains why the work moved toward Machine RSA. It does not establish that AD FS service material can never intersect a user-scoped profile.

Windows version, service-account type, whether a profile was loaded, certificate deployment method, provider, master-key history, and available backup artifacts can all change the outcome. Defenders should inventory their deployment before selecting a recovery or detection assumption. Turning one assessment's profile state into a universal product rule would leave a blind spot the moment another farm uses a different account or provider.

When live compromise is suspected, collect volatile evidence first where it can be done safely: running processes, logon sessions, open handles, network state, provider state, and queued logs. Disk history usually survives longer. The acquisition plan should also record changes it causes to timestamps, caches, or audit streams so those side effects remain distinguishable from the incident.

CNG deserves the same caution. The public report observed an active CAPI path in that environment; it did not report an active CNG key. The pinned source contains logic for multiple formats and storage locations, which supports broader capability analysis but not a claim about the assessed host. Asset inventory must record the provider actually attached to each certificate. “Not observed here” is not the same as “not supported anywhere.”

Start provider discovery at the certificate. The certificate-to-key association identifies the provider and container or key name, which then determines whether the evidence surface is a CAPI software file, a CNG key store, or an HSM call path. Folder searches follow that discovery. This direction of travel survives version and deployment changes; a hard-coded directory hunt does not.

The same artifact set may converge outside production. Registry hives can come from system-state backup, master keys from a volume snapshot, and the container from a forensic image. Monitor the repositories, restore consoles, temporary mounts, and analysis systems where those components can meet instead of treating the live directory as the only relevant location.

Tool names, filenames, and command lines remain useful supporting clues, but they are easy to replace. The more durable sequence is a privileged session reaching several sensitive object classes, followed by an unexplained signing or downstream identity outcome. Rules should describe that behavior and use recognizable tools only as additional context.

“Can read” and “can sign” are separate capabilities. A backup operator may obtain disk artifacts without being able to invoke the online provider. An AD FS service may be authorized to ask an HSM for signatures while having no way to export private bytes. A privilege model must represent both capabilities, including who can change ACLs, alter the service, reconfigure the provider, or approve device operations.

Version changes belong in validation, not in a footnote. After a Windows upgrade, service-account migration, provider replacement, gMSA adoption, or HSM deployment, repeat the mapping of object locations, audit fields, service access, and disaster recovery. The continued arrival of old event types does not prove they still cover the active key path.

The durable defensive artifact is therefore a dependency and ownership graph: which identity can access which master key or provider, which provider holds the private key for which certificate, which AD FS node invokes it, and which relying parties accept the corresponding public key. Tools, paths, and file names can change. That relationship still tells investigators what evidence must meet before a signing-risk conclusion is justified.

4 Recovering RSA bytes is not the same as identifying the active signer

A Windows cryptographic store can contain keys for many services, old renewals, abandoned applications, and administrative experiments. File names, creation dates, and physical proximity to a certificate are only candidate-generating clues. Calling a successfully decrypted RSA structure “the active AD FS signing key” skips the essential ownership question: does it match the current signing certificate, does AD FS select that certificate, and do relying parties accept its signatures?

A common matching approach derives public parameters such as the modulus from the private-key structure and compares them with public keys in the certificate store. Once the mathematics match, the analyst can attach subject, validity period, and thumbprint to the key. That proves the private key belongs to that certificate. It still does not prove the certificate is Primary, is usable on every node, or is accepted by a consumer now.

The second proof layer is configuration and runtime. Reconcile the thumbprint with the Primary entry returned by AD FS, the local store and provider on each node, federation metadata, and the signature produced by a controlled authentication. When all agree, the label “active” has evidence behind it. Any disagreement remains an open configuration or integrity investigation and cannot be rounded away.

The third layer is time. A certificate can be promoted or retired while the investigation is in progress, and consumers can remain in an overlap window after AD FS changes. Every observation needs UTC time and node identity. “Current” without a collection timestamp is an assertion whose truth decays immediately during a rollover.

4.1 CAPI, CNG, and HSM keys are different evidence objects

A CAPI software key is commonly associated with a provider and a container in locations such as ProgramData\Microsoft\Crypto\RSA\MachineKeys. CNG uses different key storage providers, formats, and directories. The APIs, ACLs, identifiers, and useful audit surfaces are not interchangeable. A forensic worksheet should state which family is present instead of labeling every Windows private key “MachineKeys.”

An HSM-backed key changes the central property: private material is designed not to exist as exportable software bytes on the host. AD FS can still request a signature through the hardware provider and device policy. That can remove the Machine DPAPI software-export branch described in this case, but it does not stop a compromised node from abusing authorized signing calls, changing claims rules, stealing established sessions, or attacking the management plane.

Moving to an HSM is therefore a service redesign, not a certificate copy. Validate device redundancy, provider support, AD FS service permissions, key generation and non-export policy, backup and recovery, audit output, disaster-recovery farms, and consumer rollover windows. A hardware control that no one has exercised under failure can trade a confidentiality risk for an authentication outage.

For existing software keys, record the provider, key specification, exportability policy, direct and inherited ACLs, and every principal that can indirectly take control of the service or host. Do not export a production key merely to prove that export might be possible. Key-to-certificate matching, provider metadata, and a controlled signature can establish identity without creating an additional plaintext copy.

Match the pair without changing production state. Compare the modulus and exponent derived from a candidate with the certificate's public key, or ask the provider to sign a harmless challenge and verify it externally. Either result proves a key relationship; active AD FS role still requires configuration, time, runtime, metadata, and consumer evidence.

ACL review must expand direct entries through inheritance and nested groups. The effective-capability graph also includes principals that can rewrite the ACL, replace the service binary, create a SYSTEM scheduled task, control the host remotely, or read a system-state backup. A container that appears restricted to SYSTEM and administrators may still be reachable through one of those delegated routes.

A service-context test matters because an administrator's certificate console can be deceptive. The certificate may display a private-key association while the AD FS service token lacks permission to open it on one node. Provider name or KeySpec mismatches can resemble corrupted material. Validation must make the actual service sign through the intended provider, with the node and resulting thumbprint recorded.

In an HSM environment, the evidence center moves from files to calls. Which node and identity requested a signature, at what time, under which policy, at what volume, and with what approval or rate control? Non-exportability does not make audit optional. It makes device and provider telemetry the primary way to distinguish expected issuance from abuse of legitimate signing authority.

Failover is part of the security design. If the HSM cluster becomes unavailable, AD FS should fail predictably; a silent fallback to an unmanaged software key would reopen the original exposure. Disaster recovery must continue to use controlled material or stop signing by design. Each exercise should capture the post-failover thumbprint so a dormant path cannot reintroduce the risk the hardware migration was meant to remove.

4.2 A reviewable active-key ledger needs more than a thumbprint

The first field group describes the farm: identifier, behavior level, database type, primary node, every member, and load-balancing path. The second captures AD FS state: certificate purpose, Primary or Secondary role, thumbprint, validity, rollover setting, and promotion thresholds. The third captures local cryptography: store, provider, container or key name, KeySpec, ACL, exportability policy, and HSM identity where applicable.

The fourth group records publication: which certificates appeared in federation metadata and when the metadata was collected. The fifth records consumption: each critical relying party's refresh method, currently trusted thumbprints, owner, and latest confirmation. The sixth records runtime proof: controlled sign-in time, selected node, observed signature, AD FS activity identifier, and downstream correlation.

The seventh group is history: installation, AD FS registration, promotion, retirement, deletion, change ticket, operator, and approver. The eighth is anomaly evidence: 385, sensitive object access, unexpected privileged logons, process and network context, and unexplained issuance gaps. The ninth is response: where a replacement key was generated, its overlap, old-public-key removal, session action, host rebuild status, and final acceptance owner.

The ledger stores no private key, DPAPI secret, or reusable token. It stores public fingerprints, controlled identifiers, hashes, event references, and responsibility. If the organization cannot populate the fields, it cannot honestly claim that configuration, host custody, publication, consumption, and session state have all converged.

Model the ledger as state transitions. Overwriting one “current value” erases the path that produced it. Secondary creation, first metadata publication, each consumer acknowledgment, Primary promotion, last acceptance of the old public key, and private-key retirement deserve separate rows. Those rows preserve the exposure and overlap windows needed for incident reconstruction and routine lifecycle review.

Automation should collect objective state, while people attest to business meaning. A script can query AD FS, node stores, and metadata; it cannot prove that an application owner tested a critical workflow or that a proprietary session was revoked. Machine evidence and accountable sign-off belong together. Neither should be used to erase the need for the other.

Reconciliation must draw from independent sources. A job that reads the same configuration database through three interfaces can consistently reproduce the same mistake. At least one check should come from the far end of the trust relationship: an observed SAML signature, the public key held by the relying party, or a sign-in record that identifies the certificate used.

Expiry alerts are the easiest metric and the least complete. Better measures include time from Secondary publication to consumer uptake, the number of applications still accepting an old public key after promotion, provider consistency across nodes, and the age of the last old-signature rejection test. These metrics describe whether rollover closed the loop, not merely whether a date remains in the future.

When a mismatch closes, “fixed” is not a sufficient status. The record should include the cause, affected interval, whether an incident review was required, the technical proof of correction, consumer confirmation, and the preventive action. A future reviewer should be able to select any thumbprint and follow it from creation through final retirement without depending on the original operator's memory.

5 An active signing key turns host privilege into downstream identity

A SAML relying party normally evaluates the signature, issuer, audience, time conditions, and its own authorization policy. A party holding the active private key can produce an assertion that is cryptographically valid; if the claims and other constraints also satisfy the trust, the consumer sees a result from its configured identity provider. Authentication controls that live only before issuance may never observe a real user completing them.

That is the central risk commonly called Golden SAML. It is not a password guess but impersonation of the issuer. Mandiant reported that, in its authorized assessment, the recovered active key signed an assertion for a Global Administrator identity and Entra accepted it. That outcome validates the full capability chain for that environment. It does not imply that every claim, every relying party, or every policy would accept any arbitrary assertion.

Scope follows the trust graph and does not stop at Microsoft 365. Every SaaS platform, internal application, VPN, administrative portal, and legacy service that trusts the same AD FS issuer and public key belongs in the inventory. Consumers differ in session duration, refresh behavior, revocation features, and log quality. An Entra session action cannot be assumed to terminate a proprietary session created by another application.

Rotating the signing key prevents the old private key from minting newly trusted assertions after consumers stop accepting its public half. It does not automatically invalidate sessions already exchanged for cookies, refresh tokens, or application-specific API credentials. Incident response must answer two questions in parallel: can the old key still create a new ticket, and how long can tickets already exchanged continue to act?

5.1 The most useful anomaly is between issuance and consumption

A federated sign-in can look ordinary in the consumer's log even when its assertion was forged. The consumer sees its trusted issuer and a valid signature; it does not necessarily know whether AD FS performed a corresponding user authentication. Detection therefore correlates the downstream acceptance with the AD FS authentication, claims processing, and token issuance that should precede it.

A normal path has at least three distinct stages. A user authenticates to AD FS or an upstream method, AD FS creates and signs an assertion for a particular audience, and the relying party validates it before creating its own session. Each stage has a different clock, identifier, and retention policy. A correlation rule must demonstrate that these stages join reliably for known-good traffic before treating an absent join as meaningful.

UPN and approximate time alone are too weak. Shared egress, batch activity, and users opening several applications create collisions. Prefer a combination of AD FS activity, relying-party identifier or audience, authentication context, signing thumbprint, source network, device evidence, normalized key claims, and the downstream request correlation. When fewer fields are available, label the result as a candidate and preserve the ambiguity.

The usable field set varies by AD FS version, audit configuration, proxy, and consumer. Preserve normalized UTC and original time, subject, audience, source, device and user agent, authentication context, security-relevant claims, signing thumbprint, issuer activity identifier, and downstream correlation where each exists. The schema and missing fields belong with the query so a later version change does not silently weaken the join.

Claim shape can add independent context. Roles, groups, authentication methods, stable subject identifiers, or other security-relevant claims that depart from the account's and application's baseline deserve review even when the source address looks familiar. Defenders can normalize only the claims needed for security correlation; collecting unrelated personal attributes adds risk without strengthening the conclusion.

Replay, clock skew, retries, and proxy transformations can produce misleading gaps. A relying party may reject a genuinely issued assertion after expiration, or log receipt several minutes away from the AD FS signing time. Before classifying a sequence, normalize UTC, identify application retry behavior, preserve unique assertion identifiers where lawful, and measure expected delay. Transport and logging behavior must be eliminated before forgery becomes the leading explanation.

“No issuance predecessor” is a strong statement only with a coverage record. The relevant farm nodes must have been online, detailed auditing enabled, forwarding healthy, queues caught up, clocks within tolerance, and the query scoped to the correct relying party. If one condition is unknown, the honest result is a telemetry gap. If all are proven and the predecessor remains absent, the anomaly deserves high-priority investigation.

Common false gaps should be tested explicitly: a missing farm node, expired local retention, clock drift, a proxy that rewrote the client context, or a parser that dropped an event variant. Those explanations lower confidence only when evidence shows they affected the exact interval and consumer; once the telemetry path is complete, an unexplained high-risk acceptance becomes the incident, not a dashboard curiosity.

Once a gap is credible, follow the downstream session. The SAML assertion may appear only at session creation; later actions may be represented by a cookie, refresh token, or application credential. Connecting the suspicious sign-in to role changes, application grants, data access, mailbox actions, key creation, or audit modification establishes whether the identity was merely presented, exchanged for durable access, or used to alter the control plane.

5.2 Scope impact by relying party, session, and observed action

Build the consumer list with fields that support response: issuer and audience, business owner, trusted thumbprints, metadata update method, session and refresh lifetimes, revocation interface, log location, and privileged roles. Include apparently retired applications until their trust is demonstrably removed. The absence of recent traffic is not the same as deletion of an accepted signing key.

The potential-exposure window begins when an unauthorized party could first have reached the active key or its signing capability, not when the certificate was issued. The start may be the earliest unexplained privileged logon, sensitive artifact read, backup export, or loss of host integrity. If it cannot be bounded, use the last trustworthy validation. The end requires universal old-key rejection plus treatment of sessions created inside the window.

Search that interval for security-relevant outcomes: account creation, role elevation, authentication-policy changes, OAuth or application consent, mailbox rules, bulk downloads, exports, new keys or certificates, and audit disruption. A signing key can theoretically represent ordinary users as well as administrators, but capability alone cannot establish impact; observed sign-ins and actions determine the grade.

Prioritize relying parties by reachable authority and response leverage. Identity administration, cloud control planes, mail, source repositories, and sensitive data systems normally precede low-privilege portals. Applications with reliable immediate revocation can be closed quickly. A legacy application that cannot invalidate sessions may require temporary trust removal, network isolation, or account action until its maximum session lifetime passes.

For each suspicious high-risk action, preserve the object, acting identity, session or request identifier, source, before-and-after state, and remediation result. “Administrator sign-in succeeded” is not an impact assessment. If the same session added an application secret, granted a persistent role, or weakened auditing, the response must include the newly created foothold even after the original session expires.

Consumers without complete logs remain unknown. A clean label has no evidentiary basis in that condition. Use their maximum session duration, possible exposure window, business sensitivity, and trust configuration to choose forced logout, account reset, downstream key rotation, temporary isolation, or explicit risk acceptance. The decision should identify the owner and the evidence that could later change it.

Long-tail trusts are often the final recovery obstacle. An application may have been dormant for years while still holding the issuer and old public key; if reactivated, it can restore acceptance of compromised material. Cross-check AD FS relying-party configuration with application inventory, network observations, and owner interviews. Orphaned trusts need a deletion or isolation deadline, not an indefinite “owner unknown” status.

The final report must separate “the key could forge trusted assertions” from “we observed a forged assertion for this identity.” The former can be high confidence after host compromise and key recovery. The latter needs an unexplained issuer-consumer gap, a downstream session, an action trail, or other independent evidence. This distinction protects both directions: it prevents capability from being exaggerated into victimization and prevents missing tool telemetry from being mistaken for safety.

Impact assessment closes only when each high-impact consumer has one explicit result: no identified effect with adequate evidence, affected and remediated, or unknown with an approved residual-risk decision. Every result is tied to a time window and log scope. If later telemetry expands or an old session produces a new action, the case must be able to reopen.

Build a session-transformation map for each critical consumer. A SAML assertion may become a browser cookie, refresh token, personal access token, or background-job credential, and some of those can mint further short-lived tokens. Record the issuer, maximum lifetime, revocation entry point, and validation method at every transition so a surviving derivative cannot hide behind expiration of the original assertion.

6 Detection must connect file access, process context, and identity outcome

Directories holding MachineKeys and SYSTEM DPAPI master-key material can be covered by SACLs so qualifying object access produces Security Event ID 4663. AD FS, certificate management, backup software, EDR, and operating-system maintenance may legitimately touch those objects. The event is therefore not a verdict. It supplies one fact: a subject, through a process, requested a particular access mask on a particular object.

Retain SubjectUserSid, SubjectLogonId, ObjectName, AccessMask, process identifier and name, computer, and UTC time. Use the logon identifier to join 4624 and 4672, service installation, scheduled tasks, remote administration, EDR process ancestry, and network activity. A stable service opening its expected key during issuance has a different shape from a short-lived privileged session reading hives, master keys, and containers in sequence.

Registry and LSA-related evidence belongs in the same view. An actor need not perform an obvious online read of LSASS. Volume snapshots, backup exports, copied hives, and offline processing can form a quieter route. Detection should focus on who combined sensitive materials, whether they were archived or moved, and whether the same context later intersected identity anomalies.

On the identity side, collect AD FS administration and audit events, certificate lifecycle state, token issuance and relevant claims, federation metadata changes, and downstream sign-ins from every consumer in scope. Host-read evidence without a discovered forged sign-in can still justify key rotation after an integrity loss. A downstream anomaly without a host-read event cannot be dismissed simply because no recognizable export tool appeared.

6.1 Event 385 is a drift sentinel; 4663 is object access, not an IOC list

In the public assessment, Event 385 helped expose certificate-state divergence. It should trigger questions with owners and deadlines: Is automatic rollover disabled? Which thumbprints are Primary and Secondary? Do node stores and metadata agree? Which change created the state? Have relying parties refreshed? The event closes only after those questions have evidence-backed answers.

The value of 4663 depends on advance audit configuration. No SACL means the event will not appear; an indiscriminate SACL can overwhelm the Security log with normal activity. Begin in a test farm or on one measured node. Observe signing, rollover, backup, EDR scanning, patching, and failover before deciding whether to audit a whole directory or selected objects.

The pilot should verify exactly which access rights appear, how often the legitimate service touches each object, and whether path, process, and logon fields survive collection. Size the local Security log and forwarding headroom for measured peaks before broader deployment. Otherwise the new SACL can erase the very evidence it was intended to create.

A path is not malicious. C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\ and C:\Windows\System32\Microsoft\Protect\S-1-5-18\ are legitimate system locations. A string-only rule will punish normal operation and train analysts to ignore it. Useful logic combines an unexpected process or identity, privileged logon, unusual access pattern, several sensitive artifact classes, archive or transfer behavior, and downstream identity context.

A familiar process name is not enough for a baseline either. A legitimate signed binary can be launched from an unusual privileged session, and an expected name can be replaced or proxied. Compare image signature and hash, path, parent, service identity, logon session, maintenance window, object combination, and subsequent network behavior. Priority rises when independently sensitive materials converge in a short interval.

Error codes have the same limitation. AADSTS500172 can result from ordinary certificate or federation configuration problems. It corrected the hypothesis in this case because a recovered WID object and a controlled assertion already existed. Production triage should correlate issuer, application, certificate validity, thumbprint where available, rollover state, and nearby administrative changes instead of treating every instance as an attack.

Central collection must preserve both normalized fields and raw event XML. Normalization enables cross-source joins; raw records preserve the original access mask, object value, and event schema for review. Forwarder loss, node silence, parser failure, and queue delay should raise telemetry-health alerts of their own. Without those checks, “no 4663” may describe a broken pipeline while saying nothing about the host.

Detection testing does not require exporting a production key. In a controlled test environment, exercise expected certificate reads, backup-copy access, provider use, and metadata change. Confirm the event travels from endpoint to SIEM with required fields and acceptable delay, then validate that the correlation escalates only when context becomes abnormal. Preserve the test inputs and result as acceptance evidence for the rule version.

6.2 An executable investigation expands from stable seeds

Use the active Primary thumbprint as one seed. Enumerate the store, provider, container, node, service usability, and last relevant access, then connect issuance and downstream sign-ins. Use the time of Event 385 as another seed and inspect certificate management, service restart, metadata change, and consumer refresh around it. Where the timelines intersect, the team can explain how the drift formed or was corrected.

When sensitive object access is the seed, expand first to the logon session and process ancestry, then to file, registry, snapshot, archive, and network activity. Unknown SYSTEM sessions, remote-management contexts, script hosts, or short-lived services deserve review. A legitimate change should lead back to a specific approval, maintenance interval, expected node, and known output.

When a downstream privileged sign-in is the seed, search for the corresponding authentication and issuance, then compare subject, claims, audience, thumbprint, source, device, and user agent. If no predecessor appears, test logging coverage and clock alignment before promoting the gap. Once coverage is proven, search the same source, session properties, and claim pattern across other identities and consumers.

A compact relationship graph keeps the investigation honest. The thumbprint connects to provider and container; container access connects to process and LogonId; LogonId connects to host and remote origin; issuance connects audience and subject; downstream acceptance connects to session and action. A missing edge becomes the next query. It does not become a narrative shortcut.

Query output should be reviewable outside the dashboard. Each conclusion carries event record identifiers, source log, UTC time, host, search conditions, and export hash. Screenshots can illustrate; they cannot replace data that a second analyst can rerun. Repeatability is especially important when a conclusion depends on proving the absence of an expected predecessor.

Confidence should rise with independent sources. A lone 385 or 4663 is a weak clue. An unexplained privileged logon combined with access to several sensitive artifact classes is stronger. A match to the active thumbprint plus a reliable issuer-consumer gap or downstream high-risk action is stronger again. Ten similar events from one log do not equal three independent layers of corroboration.

Retention sets the earliest defensible start time. If detailed AD FS audit survives seven days while a relying-party session can live for weeks, the team cannot fully reconstruct the beginning of that session later. Retention should be based on signing-key impact and the longest meaningful downstream session, with centralized access controls and cost considered before an incident removes the option.

All three paths should converge on one sentence the case file can answer: which key, on which node, was accessed by which context at what time; which assertions were issued or presented; which relying parties accepted them; and what sessions and high-risk actions followed. Until that sentence can be supported—or its missing clauses explicitly marked unknown—the detection program has produced alerts, not investigative capability.

7 Rotation ends when the old key can no longer buy a new session

1. When suspicious SYSTEM activity or a reliable issuance gap appears, preserve evidence and establish incident command before changing the farm. Capture Primary and Secondary state, provider and container per node, metadata, the relying-party inventory, active-session facts, claims-rule state, and telemetry health. If hostile activity may still be present, restrict management and egress so only approved recovery identities can operate the federation servers.
2. Generate the replacement token-signing key in a trusted environment, preferably through an HSM-backed non-exportable design. Add it through supported AD FS procedures as Secondary, prove that every intended node can use it, and publish the new public key. Do not promote merely because the certificate appears in the console. Consumers must either confirm uptake or be placed into an explicit interruption, isolation, or residual-risk decision.
3. After promotion, exercise every farm path and critical consumer. Preserve the actual signature thumbprint, AD FS activity, downstream correlation, and consumer result. Once the incident-specific overlap decision has been satisfied, remove the old public key from every trust and retire its private-key container. A public key that remains accepted by one forgotten consumer is still an open route from the old private key to a new session.
4. Where governance permits, an isolated, harmless validation using controlled test material can prove that production consumers reject an old signature. The test must not create another uncontrolled copy of the real production key. Record only the thumbprint, time, target, and rejection result. The purpose is to replace “the configuration looks updated” with evidence from the end of the trust path.

7.1 Signing ability, established sessions, and downstream persistence close on different clocks

The first response layer is signing authority: create the new key, publish it, promote it, and remove trust in the old public key. The second is federation and application sessions that already exist. The third is whatever a privileged session may have changed downstream: administrators, application registrations, OAuth grants, mailbox rules, API keys, certificates, code credentials, exports, and audit settings. Each layer has its own owner and verification.

Completing only the first layer stops the old key from creating newly trusted assertions, but an exchanged cookie or refresh token may continue. Completing only logout while retaining the old trust lets a holder of the key mint another assertion immediately. The two actions must be interlocked. Downstream control review then prevents a revoked session from surviving through a new credential or role it created.

Service-account credentials still need treatment under the host-compromise procedure, but they are not a substitute for token-signing-key rotation. A gMSA improves password generation and turnover; it does not revoke an RSA private key protected at machine scope. The recovery plan lists service identity, signing key, claims configuration, and host integrity as separate tasks with separate acceptance evidence.

If the integrity of a farm node cannot be demonstrated, rebuild it from trusted media. Deleting the visible artifact and returning the same installation to service does not restore trust. Before admission, verify patch level, management network, EDR, audit configuration, provider, HSM policy, service identity, and configuration baseline. Keep the old node isolated for forensics.

A compromised-key rollover cannot automatically inherit the overlap period used for routine maintenance. In an ordinary change, a long overlap protects availability. When the old private key may be exposed, every additional hour of dual trust extends the risk. Incident command must choose among compressed overlap, temporary application interruption, or isolation of a legacy consumer and record who accepted the residual exposure.

Review claims rules and relying-party configuration before reopening normal issuance. SYSTEM-level compromise may expose a key, but it may also alter who receives which claims. Replacing the key while preserving a malicious or accidental rules change simply gives the wrong authorization a fresh signature. Compare with a trusted baseline and require a second reviewer for high-impact transformations.

Recovery access must survive failure of the federation being repaired. If every administrator depends on the same AD FS trust, a bad promotion can lock the response team out. Tested break-glass identities and an independent management path provide continuity, but their use should generate urgent audit, be time limited, and trigger credential rotation afterward.

Session revocation must be tested, not merely invoked. Record the action time and retry with a prepared test session to confirm that its access and refresh behavior fail. For a consumer that cannot revoke immediately, use network controls, account disablement, downstream key changes, or temporary trust removal until the longest session expires. The compensating measure stays open until a concrete test passes.

Old-key rejection needs the same coverage as new-key success. One consumer rejecting does not prove the rest reject; one node signing with the new thumbprint does not prove all nodes have switched. The final matrix places “new key accepted” and “old key rejected” beside one another for every critical node and consumer. Both columns must have evidence before that row closes.

7.2 Every emergency rotation needs an independently reviewable evidence pack

Capture the pre-change state because response will overwrite it quickly. Hash exports of AD FS certificate state, node stores and providers, federation metadata, relying-party trusts, claims rules, relevant sessions, and telemetry health. In an emergency where some collection must be skipped, record the missing item, who made the decision, and which later conclusions may be limited.

The pack then records the new key's trusted generation, Secondary installation, node usability, metadata publication, consumer confirmation, Primary promotion, old-public-key removal, session action, host rebuild, and downstream review. Each item has collection time, source, operator, reviewer, and a stable identifier or hash. A series of screenshots without timestamps and source context cannot support independent review.

Change language should distinguish installation, AD FS registration, publication, promotion, consumer uptake, and deletion of old trust. Those states may be adjacent in a management interface but have different security meaning. Automation should validate each one separately, stop at a known stage on failure, and expose the rollback consequence. Blind continuation is not an acceptable recovery behavior.

Use two-person control for production transitions. One operator performs the action; a second reads back the thumbprint, node, tenant, role, and expected next state and independently confirms critical consumers. Two-person control is not two clicks by people looking at the same unverified value. The reviewer must be able to pause promotion when evidence is missing.

Rollback requires its own record. If the new certificate breaks an application, preserve the failing consumer, error, stage, and temporary choice. Restoring the old key during a compromise event may reopen a known risk, so it requires new approval, compensating isolation, and a short deadline. Removing the failed intermediate history would make the next investigator repeat the same mistake.

A second team should sample at least one node, one Microsoft relying party, and one third-party relying party. Starting from configuration, it follows provider and metadata to a real signature and downstream sign-in, then verifies old-key failure. If the reviewers cannot reproduce the path, recovery rests on the original operator's memory and the operational control is absent.

Measure discovery-to-isolation, generation-to-publication, publication-to-critical-consumer confirmation, promotion-to-old-key removal, and revocation-to-test-session failure. These intervals reveal whether the slow point is cryptography, application ownership, or coordination. The next exercise can attack the longest interval instead of celebrating a single aggregate “rotation completed” time.

Unknowns survive closure in a visible register: log blind spots, sessions that cannot be forcibly revoked, orphaned applications, consumers with uncertain refresh behavior, or nodes not yet migrated to hardware keys. Each item has a risk owner and due date. Hiding them under a completed change ticket only creates the conditions for another ghost state.

Define reopening triggers in advance. New evidence of sensitive artifact access, a consumer still accepting the old signature, activity from a supposedly revoked session, a claims-rule change, or fresh node drift should reopen the case automatically. Recovery is a conclusion based on current evidence, not a meeting decision that later evidence is forbidden to challenge.

8 Make the next investigation start from provable trust, not an expired record

The first long-term change is organizational: classify AD FS as part of the identity control plane, not as an ordinary web server. Administration should originate from dedicated privileged workstations and controlled networks. Shared administrators, generic maintenance tools, unrestricted egress, and casual interactive logon do not belong on a system that can assert enterprise identities.

The second change is to make certificate lifecycle observable. Whether rollover is automatic or manual, generation, Secondary publication, consumer uptake, Primary promotion, and old-certificate retirement need thresholds, alerts, owners, and evidence. Event 385 should not remain background noise. A thumbprint mismatch needs an explained cause and a measured time to correction.

The third change is to reduce portable signing material. An HSM-backed non-exportable key keeps private bytes inside a controlled device and gives the host only a signing interface; the host cannot reconstruct a key file from that interface. Hardware custody does not replace host hardening, but it removes one high-impact consequence of SYSTEM compromise. Device audit also creates a new source for unusual callers and signing patterns.

The fourth change is to reduce how many doors AD FS can open. Applications that can move to managed, modern, or cloud-native identity should leave the old trust through a planned migration. Only removal of the AD FS issuer and public key from the consumer reduces the blast radius. Disabling a landing page while the relying party still accepts the signature is not decommissioning.

8.1 HSM, gMSA, and automatic rollover solve different problems

An HSM addresses exportability and controlled use of the private key. A gMSA addresses generation and rotation of the service-account password. Automatic certificate rollover addresses the AD FS certificate lifecycle and advance metadata publication. The controls are complementary. A design document should name the object, threat, owner, telemetry, and acceptance test for each; the blanket claim that one feature “secures AD FS” has no testable meaning.

After adopting gMSA, verify that humans no longer manage the password, that privileges are constrained, and that service continuity is sound. Do not expect the machine-scoped RSA key to change as a side effect. After enabling automatic rollover, verify Primary and Secondary transitions plus consumer refresh. Do not infer that the resulting private key is non-exportable. After deploying HSM, verify generation, non-export policy, provider use, audit, backup, and failover. Do not infer that claims rules are clean.

Exercises should include operational friction. Start with Event 385 and an unusual 4663, then introduce a privileged relying-party sign-in with no available AD FS predecessor. Add a legacy application that imports certificates manually, one silent log forwarder, an unavailable owner, and a test session that still refreshes after revocation. The team must resolve the scenario using real contacts and tools, not by saying what it would do.

Passing the exercise requires time-bound outputs: identify the active thumbprint, establish node and telemetry health, isolate the suspect path, draft and approve the rotation sequence, contact relying-party owners, treat sessions, and assemble a reviewable evidence pack. A discussion of roles without those artifacts is preparation, not a completed exercise.

Privileged paths include more than the AD FS login screen. Backup, virtualization, monitoring, endpoint management, and recovery platforms may read memory or disk or execute as SYSTEM. They belong in the same access review. General browsing, mail, unsigned scripts, and direct administration from office networks should be absent; emergency tools should be approved, signed, recorded, and removed after use.

Prioritize migration by the trust's real use. First identify applications that can adopt managed identity, a modern protocol, or a cloud-native identity path, then map their sessions, claims, and business dependencies before moving them. Each relying party whose issuer and public key are actually removed is one fewer door an old signing key can open; redirecting traffic while preserving the trust is not retirement.

For applications that cannot migrate yet, define compensating controls: narrow audience, minimal claims, short sessions, controlled network reachability, complete logging, and a tested rapid-key-update path. Each exception has an owner and expiry. Without a date, “legacy constraint” becomes permission to retain an exportable federation dependency forever.

A quarterly control review should replay the full evidence chain, not just inspect expiration dates. Select one active thumbprint, identify its node providers, confirm metadata, inspect a critical consumer's stored public key, observe a controlled issuance and sign-in, and verify rejection of retired test material. Work that can be performed routinely will still function when an incident removes the luxury of discovery.

8.2 The final standard is not silence; it is trust that can be proved again

A healthy farm can answer, at any time: Which certificates are Primary and Secondary? Which provider does each node use? What does metadata publish? Which public keys do critical relying parties accept? Which thumbprint signed the last controlled login? Are the old private key, old public trust, and old sessions retired? The answers come from evidence, not from one administrator's recollection.

An investigable farm can also answer who read sensitive key and master-key objects, what normal service access looks like, how issuance joins to downstream acceptance, whether every node is reporting, and how quickly a logging gap is detected. Without that capability, the continuity provided by Machine DPAPI becomes an evidentiary blind spot at exactly the moment the host's integrity is in doubt.

The most valuable result in this case was the corrected judgment, not a new extraction recipe. A database object could be authentic, intact, and decryptable while remaining unable to describe runtime trust; the operating system's service-continuity key was the material the consumer still accepted. The controlled signature decided which hypothesis survived. A familiar storage location supplied only the opening clue.

The daily question therefore changes. Instead of asking only whether the database certificate can be decrypted, ask which key represents the organization now, who controls its bytes or signing interface, which systems accept the corresponding public key, and what evidence supports every answer. The first question concerns an object. The second follows trust from creation to consequence.

The absence of a known tool name or obvious export file cannot prove non-exposure. If SYSTEM integrity was lost, sensitive artifacts could meet through backup or snapshot paths, and telemetry is incomplete, the risk assessment should remain conservative. The report should still distinguish “potential key exposure” from “observed forged sign-in.” Conservative response and precise factual language are compatible.

Mature controls make important hypotheses quickly falsifiable. A 385 event leads to four-plane thumbprints within minutes. A 4663 joins to its logon and change record. A privileged federated sign-in finds its issuance and claims. A completed rotation causes an old signature to fail at every critical relying party. When those checks cannot be performed, the organization has uncertainty, not assurance.

The stale WID object in the public assessment was not lying; it was answering a question about the past. The initial error was asking a historical store to describe the entire runtime. Institutionalizing reconciliation, object audit, consumer confirmation, session testing, and old-key rejection turns that investigative correction into an operating habit.

Each recommendation should produce a visible artifact: an active-key ledger, a node test matrix, a relying-party owner list, a cross-layer correlation query, a compromise rollover runbook, an old-key rejection report, and a migration roadmap. “Improve monitoring” cannot be audited or handed to a new engineer. A named deliverable can.

Recovery is complete when configuration, host cryptography, metadata, consumer trust, and session state converge; the old key cannot create a new session; old sessions have been addressed; downstream persistence has been reviewed; and another team can replay the evidence. At that point the “ghost” is no longer an expired certificate hiding the active key. It is a drift signal the organization is designed to notice and resolve.

The risk is ultimately concrete, with no need for mystique: one server retains the ability to assert identities on behalf of an organization. As long as that authority exists, key custody, service identity, certificate lifecycle, relying-party trust, and audit evidence all need accountable owners. Silence in any one area is how a perfectly real historical record can pull the next investigation away from the key that is still signing.