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 physical server's recovery plan usually focuses on its disks. Restore the volumes, the reasoning goes, and the server comes back. For most files that is true. But a Windows server also holds keys and secrets that are tied to something other than its disks: to the Trusted Platform Module on the motherboard, or to the particular Windows installation that created them.
When the motherboard is replaced, when the TPM is cleared, or when Windows is reinstalled and the data restored on top, some of those keys do not come back. The files are there, but the server cannot use them in the same way, or at all.
This article sets out what Microsoft documents about three of these: keys and certificates held by the TPM, data protected with the Data Protection API (DPAPI), and certificate private keys more generally. It builds on the BitLocker recovery topic covered elsewhere and touches on BitLocker only briefly.
Keys that never leave the TPM
A TPM is, in Microsoft's words, a microchip designed to provide basic security-related functions, primarily involving encryption keys. It is installed on the motherboard and communicates with the rest of the system over a hardware bus.
Microsoft's TPM fundamentals page describes two properties that matter for recovery.
Non-migratable keys. When the TPM creates a key, software can choose whether it can be migrated. If it can't, the private portion of the key is never exposed outside the TPM. In our reading, a key like that cannot be backed up from the disk or copied to another server; its use remains bound to that TPM, even if encrypted key blobs are stored elsewhere.
Sealed keys. The TPM can also wrap a key so that it can be unwrapped only when those platform measurements have the same values that they had when the key was created. Microsoft calls this sealing. This is how BitLocker's TPM protector works: Microsoft's page on how Windows uses the TPM explains that BitLocker creates a key that can be used only when the boot measurements match an expected value. When the hardware or boot path changes, the measurements change, and BitLocker asks for its recovery key. That is why every BitLocker-protected volume needs a recovery key stored somewhere other than the device.
Certificates enrolled to the TPM
The same page explains that the TPM key storage provider generates keys when an organization enrolls for certificates, and that TPM-based certificates are standard certificates whose keys stay in the TPM: The usable private key is protected by the TPM; the public certificate can be copied.
Microsoft's how Windows uses the TPM page gives TPM-based virtual smart cards as one example: the TPM protects the certificate's private key so that it can't be copied when it is in use or stored and used elsewhere. Windows Hello for Business, on endpoints, works the same way. Microsoft's How Windows Hello for Business works page says the private key is stored locally and protected by the TPM, and can't be exported.
For identity credentials, recovery may involve enrolling a replacement certificate or credential with the new TPM and updating its relying services. For stored encrypted data, reissuance does not recreate the old decryption key. Identify the purpose of each key before deciding that re-enrolment is enough.
Clearing or switching the TPM
Microsoft's page on TPM initialisation and ownership is blunt about clearing it: Clearing the TPM can result in data loss. Its precautions explain why:
- Clearing causes you to lose all created keys associated with the TPM, and data protected by those keys, such as a virtual smart card or a sign-in PIN.
- Microsoft asks you to make sure you have a backup and recovery method for any data that is protected or encrypted by the TPM.
- It says to use the operating system's tools to clear the TPM rather than clearing it directly from the firmware settings, and not to clear a TPM on a device you don't own without instruction from its IT administrator.
The same page covers systems with more than one TPM where the active one can be switched in firmware. Windows doesn't support switching. If you plan to switch, Microsoft says you should toggle to the new TPM, clear it, and reinstall Windows, and it notes that toggling TPMs causes BitLocker to enter recovery mode.
In our reading, a motherboard replacement on a server with a discrete or firmware TPM has the same effect as a new TPM: the keys inside the old one are gone with the old board. Hardware vendors' service procedures may cover specific cases. The general point, from Microsoft's description of non-migratable keys, is that what lived only in the TPM cannot be carried across.
DPAPI: secrets tied to a user and a computer
Many Windows components and applications store passwords, connection strings and keys using the Data Protection API. The documentation for CryptProtectData describes its scope plainly: typically, only a user with the same logon credential as the user who encrypted the data can decrypt the data, and encryption and decryption usually must be done on the same computer.
The same page names the main exception: a user with a roaming profile can decrypt the data from another computer on the network. There is also a machine-level option. If data is protected with the local machine flag, any user on the computer on which CryptProtectData is called can decrypt it, which ties it to that computer rather than to a person.
DPAPI's protection is tied to Windows credentials and the computer, not directly to the TPM, according to these pages. Our understanding is that the risk for a server therefore lies less in a motherboard swap and more in a clean reinstall. A freshly installed Windows is, as far as DPAPI is concerned, a different computer, so application secrets restored from the old file system onto a new installation may not decrypt. Typical symptoms, as possible consequences of unavailable saved credentials, are a service that starts but cannot connect to its database, or an application that asks for credentials it used to remember. We have not tested specific products for this article. Microsoft also says the TPM may need explicit reprovisioning after an operating-system reinstall before all its features can be used. That is a provisioning requirement, not recovery of lost private keys.
Our recommendations:
- Find out which applications on each server store secrets with DPAPI. Vendors usually document this.
- Keep the information needed to re-enter those secrets (in a password manager or vault, not in a file on the server) so a rebuilt server can be reconfigured.
- Prefer full-system restores to the same or compatible hardware for servers whose applications depend heavily on DPAPI, and know when a reinstall is the only option.
Certificates in general: export, archive or re-issue
Not every certificate private key is in a TPM. Many server certificates, such as those used by web servers, live in the Windows certificate store, protected in software. Whether they can be moved depends on how they were created.
Exportable keys can be exported with their private key to a password-protected file. Microsoft's Export-PfxCertificate reference describes exporting to a Personal Information Exchange (PFX) file and says that by default, extended properties and the entire chain are exported. An export like that is a backup of the key, and in our view it deserves the protection of any other secret: a strong password, limited access, and storage away from the server.
Non-exportable keys cannot be exported that way. The certificate template or request decides this at enrolment. A replacement certificate can restore some identity functions; it cannot decrypt old data encrypted for the lost private key.
Key archival is the third option, run by an internal certificate authority. Microsoft's page on managing key archival and recovery explains why it matters: when users lose their private keys, any information that was persistently encrypted with the corresponding public key is no longer accessible. With archival configured, the certificate authority keeps an encrypted copy of the private key that a key recovery agent can later recover. The page is archived documentation written for Windows Server 2008, but its points still frame the decision:
- Key archival and recovery are not enabled by default, because many organisations consider storing a private key in several places a security vulnerability.
- Users are not protected until they enrol for a certificate that has key recovery enabled. Certificates issued before archival was turned on are not covered.
In our reading, the distinction that matters is between certificates used for identity (proving who a server or user is, as with a web server certificate) and certificates used for encryption of stored data (such as EFS). An identity certificate may be reissued, but service bindings, trust, name validation and any certificate pinning must be updated and tested. A certificate whose key encrypted stored data must have that key recoverable, or the data is gone with it.
Why the timing matters
Most of what this article describes can be handled calmly before a hardware change and only painfully after one. Before a motherboard swap, a TPM clear or a reinstall, the old server still works: certificates can be exported if their keys allow it, application secrets can be read from their vendor's console or confirmed in the vault, BitLocker recovery keys can be checked against each volume, and new certificates can be requested and installed in advance where a template allows it.
After the change, each of those becomes a recovery task done under pressure, often by someone who did not set the server up. In our view, the useful test of a server's recovery plan is not only whether its disks can be restored, but whether a person reading the plan could make the restored server do its job again without the original hardware.
A short inventory for each server
These are our recommendations, drawn from the documented behaviour above.
- BitLocker: confirm a recovery key for every protected volume is stored away from the server.
- TPM-bound certificates and credentials: list them, and record how each is re-issued (which template, which certificate authority, who approves).
- Software-protected certificates: note which are exportable; for those that are, decide whether a protected export is held, and where.
- Encryption certificates: confirm their keys are archived or otherwise recoverable before relying on them for stored data.
- DPAPI-dependent applications: list them and keep what is needed to reconfigure their secrets on a rebuilt server.
- TPM clearing: treat it as a data-loss operation; check items 1 to 5 before anyone clears or replaces a TPM.
- Test: on a non-production server, practise a motherboard-equivalent change or a clean reinstall plus data restore, and note what failed.
Distinguish the public certificate from its private key
A public certificate identifies a public key and can be copied or distributed. Recovery depends on the corresponding private key and its protection mechanism. TPM-protected key material may have encrypted representations outside the chip, but copying those files does not make a non-migratable private key usable on another TPM. This is why a certificate visible in the restored certificate store is insufficient evidence of recovery.
Classify each dependency by its use. A service identity may be enrolled again after its relying systems accept the replacement. Historical encrypted files require the original decryption key or a recovery mechanism established earlier. DPAPI-protected application secrets need the relevant user or machine protection context, with the documented roaming and domain mechanisms considered separately. A full image may preserve more of that context than a file copy, but it still cannot guarantee recovery of a lost TPM or an unavailable external key service.
Risks and limits of this article
- It is based on Microsoft documentation as read on 11 November 2026. The key archival page is archived Windows Server 2008 documentation and is used only for its general principles.
- Hardware vendors may offer procedures for specific TPM or motherboard replacements that this article does not cover.
- The effect of a reinstall on DPAPI-protected application secrets is our understanding from Microsoft's API documentation, not a tested result for any product.
- No steps were carried out for this article, and no commands were run.
Sources
Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.
- Microsoft Learn: Trusted Platform Module technology overview: TPM fundamentals
- Microsoft Learn: How Windows uses the TPM
- Microsoft Learn: Troubleshoot the TPM (initialise, clear and ownership)
- Microsoft Learn: How Windows Hello for Business works
- Microsoft Learn: CryptProtectData function (dpapi.h)
- Microsoft Learn: Export-PfxCertificate
- Microsoft Learn (archived): Managing Key Archival and Recovery
This article was originally published on .