About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
A familiar pattern after a web server is rebuilt or moved: the site comes up, the database is connected, the home page loads, and then the support calls begin. Everyone has been signed out. Some forms fail with an error about a missing or invalid token. In the worst cases, a feature that reads data the application stored in encrypted form now fails for every record.
Changed or missing application keys are one possible cause of these symptoms. The database, website files, deployment configuration and identity settings still need checking before the failure is attributed to keys.
This article explains, from Microsoft's documentation, where ASP.NET and ASP.NET Core keep these keys by default, what happens when they are lost, and how a recovery plan can account for them.
Two generations of the same problem
Applications on IIS today are usually one of two kinds:
- ASP.NET on .NET Framework, the older model, which uses a setting called the machine key.
- ASP.NET Core, the current model, which uses the Data Protection system and its key ring.
Both protect similar things: authentication cookies, anti-forgery tokens and other short-lived values the server hands to a browser and expects back. Both can also be used by application code to protect data the application stores. That second use is what turns a nuisance into data loss.
Classic ASP.NET: the machine key
Microsoft's reference for the machineKey element describes the default for both the validation key and the decryption key as automatic generation. The AutoGenerate modifier means ASP.NET generates a random key and stores it in the Local Security Authority (LSA). With the IsolateApps modifier, ASP.NET generates a unique encrypted key for each application using the application ID of each application.
The same page explains when keys must be set manually: the value must be manually set to a string of hexadecimal characters to ensure consistent configuration across all servers in a Web farm.
In our reading, the recovery consequence follows directly. An auto-generated key lives in the operating system's security store, not in the website folder or the database. A new server, or a fresh installation of Windows, generates its own key. An application restored there will not accept cookies or protected values issued by the old one. A correctly configured web farm may have an explicitly shared key, which is in a configuration file and therefore travels with the configuration backup; it is also a secret that deserves protection.
The page is archived .NET Framework 4 documentation. Our understanding is that the behaviour it describes still applies to current .NET Framework 4.x applications, but readers should check their framework version's documentation.
ASP.NET Core: the Data Protection key ring
ASP.NET Core replaced the machine key with the Data Protection system. Microsoft's article on advanced configuration of the ASP.NET Core Module and IIS explains why it matters even to applications that never call it directly: the Data Protection stack is used by several ASP.NET Core middlewares, including middleware used in authentication.
Where the keys go by default
Microsoft's page on Data Protection key management and lifetime says the app attempts to detect its operational environment and handle key configuration on its own. For applications on Windows, the documented defaults are:
- When the user profile is available, keys are stored in the profile's local application data folder and, on Windows, encrypted at rest using DPAPI.
- When the app is hosted in IIS, keys are stored to the HKLM registry in a special registry key that's ACLed only to the worker process account, also encrypted with DPAPI.
- When none of the conditions match, keys aren't persisted outside of the current process. When the process shuts down, all generated keys are lost.
The same page notes that the user-profile case depends on an application pool setting, setProfileEnvironment, which defaults to true but can be off in some environments.
The IIS advanced configuration page adds that, for standalone IIS servers, a Microsoft provisioning script can create the registry key for each application pool, and that those keys are encrypted at rest using DPAPI with a machine-wide key.
What happens when the keys are lost
The IIS page lists the effect of keys held only in memory, which is the same effect as losing them in any other way:
- All cookie-based authentication tokens are invalidated.
- Users are required to sign in again on their next request.
- Any data protected with the key ring can no longer be decrypted. The page gives anti-forgery (CSRF) tokens and TempData cookies as examples.
For cookies and tokens, the cost is a round of sign-ins and some failed form submissions. For data an application stored after protecting it with the same system, Microsoft's key management page leaves no doubt about what losing a key means: all data protected by the key is permanently undecipherable. It calls deleting a key truly destructive behavior.
Why a copy of the keys may not be enough
Here is the detail that catches restores. By default on Windows, the key ring itself is encrypted with DPAPI. Microsoft's article on key encryption at rest describes DPAPI as an appropriate encryption mechanism for data that's never read outside of the current machine, with the explicit qualifier that these keys can be backed up to Active Directory. That qualifier requires checking the actual user or machine protection context and available recovery mechanism; it is not proof that copying an IIS machine-wide key ring to a replacement server will work.
In our reading, that means a file or registry copy of the default key ring, restored onto a different server or a fresh Windows installation, is likely to be unreadable there. The keys were present in the backup but locked to the old machine. A supported full-system restore may preserve the required DPAPI context; a rebuild must establish an appropriate supported protection context. Neither outcome is proven without an application test. We have not tested this for the article.
Key lifetime: why old keys still matter
Microsoft's defaults page explains that keys have a 90-day lifetime by default. When a key expires, the app creates a new one and makes it active. Crucially, as long as retired keys remain on the system, your app can decrypt any data protected with them.
The key management page adds the detail behind this: expired keys may still be used to unprotect incoming payloads, and the normal new-key rule gives an activation date two days in the future so that other servers reading the same store can see it before it is used.
In our reading, a backup of the key ring therefore needs to include all retained keys, not just the current one. Microsoft also recommends not deleting old keys, noting that the resulting accumulation of keys generally has minimal impact because they're small. Clean-up scripts that tidy old files in an application's folders are worth checking against this.
Making the key ring recoverable
Microsoft documents ways for an application to store its key ring somewhere other than the default, and to protect it in a way that is not tied to one machine.
A shared folder. The Configure ASP.NET Core Data Protection page shows storing keys on a network share instead of the default location. The IIS page notes that keys on a UNC path aren't encrypted by default, so share permissions should be limited to the account the app runs under. The defaults page adds a warning: when the developer points Data Protection at a specific key store, automatic encryption of keys at rest is disabled until it is configured again.
A certificate to protect the keys. The key-encryption page describes distributing a shared certificate to each machine and using it to encrypt keys at rest, an approach suited to apps spread across multiple machines. For its .NET Framework-related scenario, the same page notes that only certificates with CAPI private keys are supported for that option.
Directory-based protection. On Windows 8 and later, the same page describes DPAPI-NG, where a domain controller distributes the keys and the target user can decipher the encrypted payload from any domain-joined machine when running under that identity.
Other key stores. Microsoft's key storage providers page lists options including Azure Blob Storage and Redis.
A consistent application name. The configuration page explains that the application name should match across deployments of the app. The same page’s application-isolation section says the default application identifier uses the app’s physical path. In our reading, a restored app with a changed identifier may therefore be unable to unprotect its existing payloads even when the key ring is readable.
Each of these moves the recovery question rather than removing it. A shared folder must be backed up. A protecting certificate, with its private key, must be backed up or recoverable, or the key ring it protects is as lost as before. These choices belong to the application's developers, which is why the recovery plan needs their input.
Planned moves and unplanned rebuilds
The same gap shows up in two very different situations. In a planned move to a new server, the old server is still running, so the keys can be located and handled with the developer's help before the change, and users can be told to expect one more sign-in if that is acceptable. In an unplanned rebuild after a failure, the old server may be gone. If the keys were tied to it, the only remaining choices are the ones made earlier: a recoverable key store, or accepting that protected data is lost. In our view, that difference is the reason to answer the questions below while everything still works.
Questions to ask before you need the answer
Our recommendations for each ASP.NET or ASP.NET Core application on a server:
- Which model is it? .NET Framework with a machine key, or ASP.NET Core with Data Protection?
- For a machine key: is it auto-generated or set? If set, where is the value kept, and is that location protected and backed up?
- For Data Protection: where is the key ring? Default profile folder, registry, a share, or an external store? Is it protected with DPAPI, a certificate, or directory-based protection?
- Does the application protect stored data with these keys, or only cookies and tokens? Ask the developer; this decides whether key loss is an inconvenience or data loss.
- Would a restored copy of the keys work on a different server? If they are DPAPI-protected, identify the exact user or machine scope and prove the applicable recovery path; do not assume a file copy is portable.
- Where is the protecting certificate, if any, and is its private key exportable and backed up?
- Is the application name fixed in configuration, so a move to a new path does not change it?
- Has the restore been tested with a signed-in user, an anti-forgery protected form and any feature that reads protected data?
A readable key ring is only part of application compatibility
The Data Protection application name is an isolation setting. A mismatch can prevent unprotecting cookies or other payloads even when both deployments can read the same key files. Keep the intended application name consistent across deployments that must share protected data, and keep unrelated applications isolated. Also preserve the relevant application version, authentication settings and purpose-specific configuration; changing them can invalidate data independently of the key store.
Record the target runtime rather than applying a .NET Framework certificate-provider restriction to every modern ASP.NET Core deployment. For a recovery rehearsal, distinguish expected session expiry from permanent loss: a user signing in again may be acceptable, whereas an application unable to decrypt retained business values is not. Check an older protected value as well as a newly generated token. New tokens succeeding only proves that the replacement deployment can use its new keys.
Risks and limits of this article
- The machineKey reference is archived .NET Framework 4 documentation.
- The effect of restoring a DPAPI-protected key ring to another machine is our reading of Microsoft's description of DPAPI, not a tested result.
- Some applications use their own encryption rather than these systems; their vendors' documentation applies.
- No commands or scripts were run for this article.
Sources
Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.
- Microsoft Learn (archived): machineKey Element (ASP.NET Settings Schema)
- Microsoft Learn: Advanced configuration of the ASP.NET Core Module and IIS
- Microsoft Learn: Data Protection key management and lifetime in ASP.NET Core
- Microsoft Learn: Key management in ASP.NET Core
- Microsoft Learn: Key encryption at rest in Windows and Azure using ASP.NET Core
- Microsoft Learn: Configure ASP.NET Core Data Protection
- Microsoft Learn: Key storage providers in ASP.NET Core
This article was originally published on .