DPAPI and Windows Secret Stores: Defensive Guide

Every Windows machine holds a layer of saved secrets that most security teams never inventory: browser passwords, Credential Manager entries, service account passwords in LSA secrets and cached domain logons, much of it protected by the Data Protection API (DPAPI). Attackers who reach a workstation or server as the user or as SYSTEM go after these stores because they turn one compromised host into many compromised accounts. This guide explains what each store holds, how DPAPI protects it and where that protection ends, which protections Microsoft provides (Credential Guard, LSA protection, the LSASS attack surface reduction rule, Windows LAPS encryption) and how to detect and measure misuse. It is written for Windows platform, endpoint and identity engineers, and it is defensive: it covers what attackers target at a high level, not how to extract anything.

Key takeaways

DPAPI protects data, not the logged-on user. In the default user scope, anything running as that user can ask Windows to decrypt that user's protected data, which is why infostealers running in the user session can read browser and Credential Manager secrets.
Machine scope is weaker than it sounds. Data protected with the CRYPTPROTECT_LOCAL_MACHINE flag can be decrypted by any user on that computer, so it is not a safe place for service credentials.
Service accounts with stored passwords are the NHI exposure. Services configured with a password keep it in LSA secrets, readable by anyone with SYSTEM on the host. Replace them with gMSA or virtual accounts where you can.
Credential Guard and LSA protection cover LSASS, not everything. Credential Guard isolates NTLM hashes, Kerberos TGTs and domain credentials; it does not protect generic Credential Manager entries, the SAM or browser stores.
Reduce what is stored, then watch who reads it. Turn off browser password saving for managed browsers, lower cached logons, remove saved credentials from servers, and alert on unusual access to credential store files and LSASS.

What DPAPI is and how its scopes differ

DPAPI is a Windows interface for encrypting static data on a single computer. Microsoft describes it as two functions, CryptProtectData and CryptUnprotectData, designed for developers who knew little about cryptography. The caller hands Windows a blob, Windows derives a session key, encrypts the blob and adds a keyed integrity check (MAC), and returns ciphertext the application can store anywhere: a file, a registry value or a database column. The application never handles the key.

User scope (default): Microsoft's documentation states that typically only a user with logon credentials matching those of the user who encrypted the data can decrypt it, and usually only on the same computer; users with roaming profiles can decrypt from other machines. In practice the protection is tied to the user's master keys, which Windows protects using the user's logon secret and, on domain-joined machines, can recover with help from a domain controller.
Machine scope (CRYPTPROTECT_LOCAL_MACHINE): the data is associated with the computer, and any user on that computer can call CryptUnprotectData on it. This is convenient for services and dangerous for secrets.
Optional entropy: the caller can supply an extra secret (entropy) that must be presented again at decryption. It raises the bar slightly, but the entropy usually lives in the same application, so it is obfuscation rather than a security boundary.
DPAPI-NG (CNG DPAPI): from Windows 8, Microsoft extended DPAPI so a secret can be protected to a set of principals, such as an Active Directory group, and decrypted on another computer after authentication and authorisation. It is built on Cryptography Next Generation (functions such as NCryptProtectSecret). Windows LAPS uses it to encrypt local administrator passwords stored in Active Directory.

The key point for defenders: DPAPI defends data at rest against someone who copies a disk or a file without the user's or machine's secrets. It does not defend against code that is already running as the user, or as SYSTEM on the machine, because that code can simply ask Windows to decrypt. Domain environments add a further dependency: domain controllers hold a DPAPI backup key that can recover user master keys, which is one more reason domain controllers are tier 0 assets.

The Windows secret stores and what they hold

The table lists the stores that matter for credential exposure, how each is protected and the ATT&CK technique that describes attacker interest in it. Technique IDs are from ATT&CK v20.

Store	What it holds	Protection	Who can read it	ATT&CK
Credential Manager: Windows Credentials locker	Saved network and application credentials (RDP, file shares, apps using NTLM or Kerberos)	Encrypted `.vcrd` files in the user profile, user DPAPI; domain credentials isolated when Credential Guard is on	The user's session; with Credential Guard, domain credentials cannot be extracted	T1555.004 Windows Credential Manager
Credential Manager: Web Credentials and generic credentials	Website passwords for legacy Microsoft browsers, generic user name and password pairs saved by applications	User DPAPI only	Anything running as the user; Credential Guard does not protect generic credentials	T1555.004
Browser password and cookie stores	Website passwords, session cookies, autofill data	Browser profile database with values protected by user DPAPI, plus browser-specific hardening	Code running as the user is the main risk	T1555.003 Credentials from Web Browsers
LSA secrets	Passwords for services that run under a named account, other system credentials	Registry under `HKLM\SECURITY\Policy\Secrets`, protected by machine keys	SYSTEM on the host	T1003.004 LSA Secrets
Cached domain credentials	Verifiers for recent domain logons so users can sign in without a domain controller	DCC2 (MS-Cache v2) hashes in the registry	SYSTEM; requires offline cracking, cannot be passed	T1003.005 Cached Domain Credentials
LSASS memory	NTLM hashes, Kerberos tickets, sometimes reusable secrets for signed-in sessions	Process memory; LSA protection and Credential Guard	Administrators or SYSTEM without protections	T1003.001 LSASS Memory
Security Account Manager (SAM)	Local account password hashes	Registry hive, machine keys; not covered by Credential Guard	SYSTEM	T1003.002 Security Account Manager
Application files and registry	Connection strings, API keys, tokens in config files or registry values, sometimes DPAPI-wrapped	Varies: none, file ACLs, or DPAPI	Depends on ACLs and scope	T1552.001 Credentials In Files, T1552.002 Credentials in Registry

Microsoft's Credential Guard documentation is explicit about the split inside Credential Manager: domain credentials stored there are protected with Credential Guard, while generic credentials, such as user names and passwords for websites, are not, because the applications need the clear-text password. If an application does not need the password itself, it can save it as a Windows credential instead. Credential dumping from LSASS and the SAM is covered in depth in the Credential Dumping Guide; this page concentrates on the at-rest stores around it.

What attackers target, at a high level

Attacker interest in these stores follows two privilege levels, and the defensive answer differs for each.

Running as the user: commodity infostealers and phishing payloads run in the user session. ATT&CK T1555.003 describes how browser stores are read and then passed to CryptUnprotectData, which uses the victim's own logon context to decrypt them. Nothing here needs administrator rights, which is why browser passwords and cookies are the most common haul. See the Infostealer Threat Guide.
Running as SYSTEM or administrator: after privilege escalation the attacker can read LSA secrets, cached credentials, the SAM, machine-scope DPAPI data and, without protections, LSASS memory. On servers this is where service account passwords and saved credentials for scheduled jobs and integrations surface.
Domain-level: an attacker who controls a domain controller can use the domain DPAPI backup key to recover users' DPAPI-protected data across the domain. Treat domain controller compromise as compromise of every domain user's DPAPI-protected secrets, and plan recovery accordingly.
Offline: stolen disk images or backups of profiles and registry hives become valuable if the attacker also obtains the user's password or the machine keys. Full disk encryption (BitLocker) and protected backups reduce this path.

The Snowflake breach shows the downstream effect: infostealer malware on contractor and employee machines harvested saved cloud credentials, and accounts without MFA or network restrictions were then used to take customer data. The secret store on the endpoint was the start of the chain, the missing controls on the service were the rest.

Where identity fits: service accounts and other NHIs on hosts

The non-human identity exposure on Windows hosts is concentrated in a few patterns. Each is a credential that a person typed in once and that now sits in a store readable by SYSTEM.

Services with a named account and password: the password is stored as an LSA secret (ATT&CK T1003.004 notes that LSA secrets can contain credentials for service accounts). Any admin on that server can recover it, so the effective blast radius of the account is every host it is configured on. Move to Group Managed Service Accounts (gMSA), where Windows manages a long random password, or to virtual accounts for local-only services. See How to convert AD service accounts to gMSA.
Scheduled tasks and integration jobs with saved credentials: the same issue as services. Inventory tasks set to run whether the user is logged on or not with a stored password, and replace them with gMSA where the job supports it.
Application secrets wrapped in machine-scope DPAPI: developers often use CRYPTPROTECT_LOCAL_MACHINE to encrypt API keys and connection strings in config files. Microsoft's documentation confirms any user on that computer can decrypt it. Move the secret to a vault, or use a managed identity or workload identity federation where the platform supports it. See the Secrets Management Guide.
Local administrator passwords: Windows LAPS rotates them and, with encryption on, encrypts them in Active Directory using CNG DPAPI (AES-256), decryptable only by one configured principal (by default Domain Admins of the device's domain, set with ADPasswordEncryptionPrincipal). Microsoft highly recommends enabling encryption and says never to grant a managed device permission to decrypt any encrypted password, including its own.
Privileged admin credentials saved on servers: admins who tick "remember my credentials" in Remote Desktop leave domain credentials in Credential Manager on jump hosts. With Credential Guard enabled, saved Windows credentials used by the Remote Desktop client cannot be sent to a remote host, which breaks this habit by design.

Protections and what each one covers

Protection	What it protects	What it does not protect	Key settings and requirements
Credential Guard	NTLM hashes, Kerberos TGTs and credentials stored by applications as domain credentials, isolated in LSAIso.exe by virtualisation-based security	The SAM and the Active Directory database, generic Credential Manager entries, browser stores, attacks from a compromised Hyper-V host	VBS and Secure Boot required; TPM and UEFI lock recommended; Enterprise or Education edition; default-on for Windows 11 22H2 and later and domain-joined Windows Server 2025 (not domain controllers) when requirements are met
LSA protection (RunAsPPL)	Runs LSASS as a protected process so non-protected processes cannot read its memory or inject code	Secrets outside LSASS: browser stores, files, LSA secrets on disk read by SYSTEM	`RunAsPPL` under `HKLM\SYSTEM\CurrentControlSet\Control\Lsa`: 1 with UEFI lock, 2 without (Windows 11 22H2+); Group Policy "Configures LSASS to run as a protected process"; Intune OMA-URI `./Device/Vendor/MSFT/Policy/Config/LocalSecurityAuthority/ConfigureLsaProtectedProcess`
ASR rule: Block credential stealing from the Windows local security authority subsystem	Blocks access to LSASS process memory	Other stores; not needed where LSA protection is enabled	GUID `9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2`; requires Microsoft Defender Antivirus; no Warn mode
Cached logon limit	Reduces the number of DCC2 verifiers on a host	Live sessions	"Interactive logon: Number of previous logons to cache" default 10, range 0 to 50; Microsoft suggests 0 where availability allows, 2 for mobile devices
Windows LAPS with encryption	Unique, rotated local admin passwords encrypted in AD with CNG DPAPI	Other local accounts	Windows Server 2016 domain functional level or later; one decryption principal
Managed browser policy	Stops passwords being saved in the browser store at all	Session cookies	Disable the built-in password manager for managed profiles and provide an enterprise password manager
BitLocker	Offline access to profiles and hives from a stolen disk	Anything once Windows is running	TPM-backed protector, recovery keys escrowed

Choosing between them

Licensed Enterprise or Education fleet on modern hardware: rely on Credential Guard plus LSA protection; the ASR rule adds nothing where LSA protection is on.
Fleets that cannot run Credential Guard: Microsoft notes that custom smart card drivers or other software loading into LSA can block it; in that case enable the LSASS ASR rule for equivalent protection against malware targeting lsass.exe, and still enable LSA protection where plug-ins are signed.
Pro edition devices: Credential Guard is not supported on Windows Pro or Pro Education, so LSA protection, the ASR rule, browser policy and least privilege carry the load.
Domain controllers: Microsoft does not recommend Credential Guard on domain controllers. Protect them as tier 0 with LSA protection, restricted admin access and the backup key treated as a crown jewel.
Small organisations: the highest return is usually turning off browser password saving, deploying an enterprise password manager, enabling Windows LAPS and removing standing local admin rights. Large organisations add Credential Guard compatibility testing and service account migration at scale.

How to implement: a phased approach

Inventory stored secrets. List services and scheduled tasks running under named domain accounts, servers where admins have saved RDP credentials, applications using machine-scope DPAPI for config secrets, and the browser password manager setting across managed browsers. This inventory is the baseline for every later metric.
Turn on LSA protection in audit mode first. Set AuditLevel to 8 under Image File Execution Options\LSASS.exe (on by default in Windows 11 22H2 and later), then review CodeIntegrity Operational events 3065 and 3066 for plug-ins that would fail. Fix or replace unsigned drivers, then enforce. Use the setting without UEFI lock (value 2) during pilots so you can roll back remotely; note that setting the Group Policy to "Not Configured" does not undo a previous Enabled setting.
Pilot Credential Guard by ring. Test applications that need NTLMv1, Kerberos DES, unconstrained delegation, MS-CHAPv2 Wi-Fi or VPN, or saved RDP credentials, because Microsoft lists these as breaking or degraded. Watch NTLM Operational events 4013 and 4014. Default enablement does not use UEFI lock, which keeps remote disablement possible for rollback.
Back up before you switch. Microsoft notes that Windows credentials backed up from a PC with Credential Guard enabled cannot be restored, so users who need them must back up first, and clearing the TPM deletes saved Windows credentials.
Migrate service accounts. Convert services and tasks to gMSA or virtual accounts, rotate the old passwords after cutover (they have been readable in LSA secrets on every host), then disable the old accounts.
Remove machine-scope DPAPI secrets from applications. Move them to a vault or managed identity; where an application must keep a local secret, restrict the file ACL to the service identity and protect it in user scope for that identity.
Reduce cached and saved credentials. Lower cached logons on servers (0 where a domain controller is always reachable), block browser password saving for managed profiles, and remove saved Windows credentials from jump hosts.
Enable Windows LAPS encryption with a dedicated decryption group and confirm the old LAPS or manual local admin passwords are retired.

Detection and measurement

Signal	Source	What it tells you
Non-browser process opening browser profile credential databases	EDR file telemetry	Possible infostealer activity (T1555.003)
Processes reading Credential Manager vault files or enumerating credentials outside expected tools	EDR file and API telemetry	Possible T1555.004 activity
Access to the `HKLM\SECURITY` hive or saving of SECURITY, SYSTEM or SAM hives	EDR registry telemetry, object access auditing	LSA secrets or cached credential theft (T1003.004, T1003.005, T1003.002)
`AsrLsassCredentialTheftBlocked` or `AsrLsassCredentialTheftAudited`	Microsoft Defender advanced hunting	Attempts to read LSASS memory; one event alone is not proof of compromise
WinInit event 12 "LSASS.exe was started as a protected process with level: 4"	System log	LSA protection is actually running, useful for coverage measurement
Events 4692 and 4693 (backup and recovery of a data protection master key)	Security log, Audit DPAPI Activity subcategory	Low volume and mainly for troubleshooting per Microsoft; unexpected 4692 or 4693 activity against domain controllers is worth reviewing
Sign-ins by service accounts from hosts outside their expected set	Domain controller authentication logs, identity threat detection	A harvested service account password being reused

Metrics that show progress:

Percentage of eligible devices with Credential Guard running and LSA protection confirmed (event 12 or device health reporting).
Number of Windows services and scheduled tasks running under named domain accounts with stored passwords, trending to zero.
Percentage of managed browser profiles with built-in password saving disabled.
Servers with more than zero cached logons or saved Windows credentials for privileged accounts.
Mean time to rotate credentials after an infostealer detection on an endpoint (see the Infostealer Logs Monitoring and Response Guide).

Common failure patterns

Assuming DPAPI encryption means safe: teams see "encrypted with DPAPI" in a vendor answer and stop asking. If the secret is in machine scope, every user on the box can read it; in user scope, every process running as that user can.
Service accounts with Domain Admin rights installed on many servers: one admin on any server can recover the password from LSA secrets and own the domain. See How to find service accounts with Domain Admin rights.
Credential Guard counted as covering browser and generic secrets: it does not. The infostealer path runs straight past it.
No rotation after an endpoint compromise: reimaging the machine does nothing for the passwords and cookies already taken. Credentials saved on that host must be treated as exposed, as the Snowflake breach illustrates.
UEFI lock applied during a pilot: rolling back then needs the opt-out tool at the console. Pilot without the lock, apply it once stable if you need it.
Forgetting domain controllers hold the DPAPI backup key: recovery plans that rebuild the domain but leave users' DPAPI-protected data trusted miss part of the exposure.

Framework mapping

Framework	Reference	How it applies
MITRE ATT&CK v20	T1555.003, T1555.004, T1003.001, T1003.002, T1003.004, T1003.005, T1552.001, T1552.002	Techniques targeting the stores on this page
MITRE ATT&CK mitigations	M1043 Credential Access Protection, M1025 Privileged Process Integrity, M1026 Privileged Account Management, M1027 Password Policies	Credential Guard, LSA protection, admin restriction, password policy
MITRE D3FEND	D3-CH Credential Hardening	Reducing stored and reusable credentials
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management, SC-28 Protection of Information at Rest, AC-6 Least Privilege	Protection and rotation of stored authenticators, at-rest encryption, limiting who can read stores

Practitioner checklist

Inventory services, scheduled tasks and applications that store passwords or secrets on Windows hosts.
Find application secrets protected with machine-scope DPAPI and move them to a vault or managed identity.
Enable LSA protection in audit mode, clear CodeIntegrity 3065 and 3066 events, then enforce.
Pilot and enable Credential Guard on eligible devices, testing NTLMv1, MS-CHAPv2 and saved RDP credential dependencies.
Use the LSASS ASR rule where Credential Guard cannot run.
Convert service accounts to gMSA and rotate the old passwords after cutover.
Disable built-in browser password saving for managed profiles and provide an enterprise password manager.
Set cached logons to 0 on servers where availability allows, and 2 on laptops.
Enable Windows LAPS password encryption with a dedicated decryption group.
Alert on non-browser access to browser stores, SECURITY hive access and LSASS access attempts, and rotate all credentials saved on a host after any compromise.

DPAPI and Windows secret stores: what Windows keeps, what attackers target, how to defend