MSIX Persistent Identity: Digital Certificate Renewal Without Breaking App Updates

What is MSIX Persistent Identity?

MSIX Persistent Identity is a Windows feature that allows developers to sign future versions of an MSIX package with a new certificate while maintaining the application's existing package identity. Instead of treating the app as a new package, Windows recognizes the link between the old and new certificates and allows users to update as normal.

This matters most when you’re renewing an expiring certificate, migrating to a different certificate authority, or complying with new security requirements, and you don’t want any of that disrupting app updates.

Each code-signing certificate has a limited validity period. Developers will eventually need to replace it due to expiration, organizational changes, or security policies.

Without Persistent Identity, replacing the signing certificate often implies the following:

• Existing users cannot directly upgrade
• The operating system treats the package as a different application
• Users may need to uninstall the previous version before installing the new one
• Application settings and update continuity may be affected

For enterprise software vendors and ISVs with thousands of deployed applications, this can result in unnecessary support requests and poor user experiences. MSIX Persistent Identity removes this friction by allowing Windows to trust the transition from the old certificate to the new one.

How Persistent Identity Works

The feature creates a secure trust relationship between the old and new signing certificates.

Instead of simply signing the package with a different certificate, developers generate a publisher bridging artifact that proves the new publisher is authorized by the original certificate.

The overall workflow includes:

1. Create an XML artifact that defines the relationship between the old and new publisher certificates. You can name it anything you like (artifact.xml):

<?xml version="1.0" encoding="UTF-8"?>
<Publisher xmlns="http://schemas.microsoft.com/appx/publisherbridging/2021" Old="CN=WLDSoftware2025" New="CN=WLDSoftware2026New" />

2. Create a Catalog Definition File (CDF) to specify the catalog that will be used to sign the artifact. You can name it anything you like (artifact.cdf):

[CatalogHeader]
Name=artifact.cat
CatalogVersion=2
HashAlgorithms=SHA256
[CatalogFiles]
<HASH>artifact.xml=artifact.xml

3. Generate a catalog (.cat) file for the XML artifact:

makecat.exe artifact.cdf

4. Sign the catalog using the original certificate:

signtool.exe sign /f WLDSoftware2025.pfx /p MyPassword
/fd SHA256 artifact.cat

5. Create a publisher bridging file that references the XML and catalog. You can name it anything you like (artifact.txt):

[PublisherBridging]
"artifact.xml" "artifact.cat"

6. Build the MSIX package using the publisher bridging information:

makeappx.exe pack /p MyApp.msix /d .\app\ /pb artifacts.txt

7. Sign the final MSIX package with your new certificate:

signtool.exe sign /f WLDSoftare2026New.pfx /p MyPassword
/fd SHA256 MyApp.msix

When Windows installs the updated package, it validates the bridging artifact and recognizes that the new certificate legitimately replaces the previous one. That preserves the package identity and allows for a standard upgrade.

Requirements

Before you put Persistent Identity in place, keep a few things in mind:

• You still need access to the original signing certificate
• Build the bridging artifact before the old certificate expires
• Microsoft recommends catalog file timestamping: without a timestamp, the artifact becomes unusable when the original certificate expires
• The old certificate still needs to be trusted on the target machine during the transition
• The feature works with both MSIX packages and MSIX bundles

Plan your certificate rotation early. Wait until after the certificate expires, and you lose the chance to build the trust relationship.

Conclusion

With MSIX Persistent Identity, you can safely and reliably maintain application identity while you move to a new signing certificate.

As software security requirements keep changing, integrating Persistent Identity into your release process can save you time, decrease operational risk, and improve the overall experience for both administrators and end users.