msixmgr release binaries are unsigned or signed with Microsoft Testing PCA 2010 — blocks use in high-assurance environments

Summary

The binaries shipped in the msixmgr ZIP (https://aka.ms/msixmgr) contain a mix of unsigned and test-signed files. This makes it impossible to verify their authenticity before deployment in environments where Authenticode verification of all toolchain binaries is mandatory (DoD, NATO, financial, healthcare, etc.).

Affected binaries (latest ZIP as of 2026-05-20)

Microsoft Testing PCA 2010 is a test/internal CA whose root is not present in the Windows trusted-root store on end-user or server machines.

Impact

Any security-conscious automation layer that calls Get-AuthenticodeSignature and checks the result before executing a downloaded binary will fail (Status ≠ Valid, or signer subject not in a Microsoft production-CA allowlist). Concretely:

• Our open-source MSIX PowerShell module runs Get-AuthenticodeSignature on every downloaded binary and checks the leaf-signer subject against a trusted-publisher allowlist (CN=Microsoft Corporation,, CN=Microsoft Windows,, etc.) before use. Install-MsixMgr currently fails at the Authenticode verification step with:

  Authenticode verification FAILED for msixmgr/msixmgr.exe
  Status: NotSigned
  

  or, for the test-signed DLLs:

  Authenticode verification FAILED for msixmgr/ApplyACLs.dll
  Signer is NOT in the trusted-publisher allowlist:
    Subject: CN=Microsoft Testing PCA 2010, O=Microsoft Corporation, ...
  

• Windows Defender Application Control (WDAC) / AppLocker policies that require Microsoft as the Authenticode publisher will block these files on managed endpoints.

Expected behaviour

All binaries in the msixmgr distribution ZIP should be signed with a production Microsoft Authenticode certificate (the same CA chain used by signtool.exe, MakeAppx.exe, msixmgrSetup.exe, etc.) so that Get-AuthenticodeSignature returns Status = Valid with a subject matching CN=Microsoft Corporation, or equivalent production signer.

Suggested fix

1. Add all .exe and .dll files in the msixmgr build pipeline to the production code-signing step.
2. Replace any internal test-signing step for ApplyACLs.dll, CreateCIM.dll, and WVDUtilities.dll with the same production signing used for the outer msixmgrSetup.exe.

Workaround (temporary)

Until this is fixed, consumers who need the binaries can either:

• Add CN=Microsoft Testing PCA 2010 to their local allowlist (not acceptable in high-assurance environments).
• Skip Authenticode verification for msixmgr specifically (weakens the security posture of the toolchain).

We have filed this so we can track it and remove the workaround once production-signed binaries are available. A reference to this issue will be added to the module's Install-MsixMgr warning output.

References

• msixmgr download: https://aka.ms/msixmgr
• msix-packaging source: https://github.com/microsoft/msix-packaging/tree/master/tools/msixmgr
• Related: MSIX Packaging Tool signing requirements

Start in the msixmgr source under tools/msixmgr and inspect the build and signing steps that produce the ZIP at https://aka.ms/msixmgr. Use Get-AuthenticodeSignature on every listed EXE and DLL to confirm the current states. Done means all distribution binaries return Status = Valid with a production Microsoft signer rather than Microsoft Testing PCA 2010.