Auditing Windows Credential Roaming: The Forgotten AD Feature That Syncs Private Keys

Credential Roaming quietly replicates certificates, DPAPI keys, and private keys into Active Directory attributes attackers can read. Here's how to audit it.

Credential Roaming is one of those Windows features that solved a real problem in 2007 and has been quietly ticking along ever since — copying a user's certificates, DPAPI master keys, and stored credentials into their Active Directory user object so those secrets follow them from machine to machine. It predates roaming profiles feeling old, most admins have forgotten it exists, and that is exactly why it deserves an audit. The data it writes into AD is readable by any authenticated user, and it has a history of leaking private key material onto disk.

What Credential Roaming actually does

When enabled by Group Policy (User Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Certificate Services Client - Credential Roaming), Windows serializes the contents of the user's certificate stores and DPAPI keys and writes them into a set of attributes on the user's AD object:

msPKI-CredentialRoamingTokens — the roamed certificates and keys
msPKIAccountCredentials — DPAPI master keys and stored credentials
msPKIRoamingTimeStamp and msPKIDPAPIMasterKeys — sync metadata and key blobs

The client-side extension then rehydrates that state on every machine the user logs into. Convenient in a pre-cloud world. In 2026 it is mostly dead weight that widens your credential attack surface.

Why an attacker cares

Two problems make this a live risk, not a theoretical one.

1. The attributes are readable by low-privilege accounts. The default ACL on these attributes lets any authenticated domain user read msPKI-CredentialRoamingTokens and friends on other users. That means a single compromised standard account can enumerate roamed certificate material domain-wide — including certificates that map to authentication (think PKINIT / smartcard-logon templates). If a roamed cert allows client authentication, reading it can be a direct path to impersonating that user.

2. It leaks private keys to disk (CVE-2022-30170). Microsoft patched a flaw where Credential Roaming wrote private key files into the user's roaming directory with weak permissions and stale copies that were never cleaned up. On unpatched or legacy-configured estates, you can still find orphaned .key and PFX-adjacent files under %APPDATA%\Microsoft\Crypto and %APPDATA%\Microsoft\SystemCertificates that should never have persisted.

The uncomfortable summary: a feature nobody remembers enabling is copying private keys into an AD attribute that half your domain can read.

How to audit it

Check whether the policy is on

Look for the GPO setting above, then confirm it is actually applied on endpoints via the registry key the CSE writes:

reg query "HKCU\Software\Policies\Microsoft\Cryptography\AutoEnrollment" /v CredentialRoaming

A value of 1 means roaming is active for that user context.

Find users with roamed material in AD

From a domain-joined host, enumerate objects that actually carry roaming attributes — these are your exposure surface:

Get-ADUser -Filter * -Properties msPKI-CredentialRoamingTokens, msPKIAccountCredentials |
  Where-Object { $_.'msPKI-CredentialRoamingTokens' -or $_.msPKIAccountCredentials } |
  Select-Object SamAccountName,
    @{n='TokenBytes';e={ ($_.'msPKI-CredentialRoamingTokens' | Measure-Object -Sum Length).Sum }}

Any account showing bytes here has secrets serialized into the directory. Cross-reference against which of those certificates enable client authentication — those are the ones worth losing sleep over.

Hunt for leaked key files on disk

On sampled endpoints, look for private-key artifacts that outlived their purpose:

Get-ChildItem "$env:APPDATA\Microsoft\Crypto\Keys",
  "$env:APPDATA\Microsoft\SystemCertificates\My\Keys" -File -ErrorAction SilentlyContinue |
  Select-Object FullName, Length, LastWriteTime

Stale files with old timestamps on a machine the user no longer actively uses are the CVE-2022-30170 fingerprint.

Remediation

Patch first. Ensure the August 2022 (or later) cumulative update is deployed everywhere before you touch anything else — that closes the private-key-leak behavior.
Disable the policy if you no longer need cross-machine secret sync. Modern estates using Windows Hello for Business, LAPS, and cloud-managed certificates rarely do.
Clean up the AD attributes. Disabling the GPO does not retroactively purge msPKI-CredentialRoamingTokens; you must clear the populated attributes on affected user objects after confirming no legitimate dependency.
Tighten the ACLs where you cannot remove the feature, so the roaming attributes are not world-readable by authenticated users.
Rotate any certificates that were roamed and could authenticate — assume the material was exposed.

Where WinSentinel fits

Credential Roaming is exactly the kind of dormant, forgotten setting a point-in-time pen test misses and a dashboard never surfaces. WinSentinel audits the local Credential Roaming policy state, flags leaked private-key artifacts under the crypto directories, and reports patch currency for CVE-2022-30170 as part of its credential-exposure module — all 33 modules run in full on the free single-machine agent, no limits. For an organization running dozens or hundreds of endpoints, WinSentinel Pro rolls those findings up across the fleet: you see which machines still have roaming enabled, catch drift when a GPO re-enables it, and get alerted when a previously clean node regresses — so a decade-old feature does not quietly reopen your credential attack surface across the estate.

Audit the boring, forgotten settings. Attackers already have.