A self-signed code signing certificate is acceptable for testing on machines you control. It is not acceptable for software you ship to users, because other computers have no reason to trust it. Microsoft's documentation says the same: use self-signed certificates for testing, and a trusted authority for release.
Definition
A self-signed certificate is one you issue yourself, so your own computer acts as the authority. A normal code signing certificate is issued by a public certification authority that checks your identity first. Operating systems trust the public authority, so they trust what it vouches for.
What the documentation says
Microsoft's PowerShell and MSIX guidance both address the case.
- A self-signed certificate is free and lets you write, sign and run scripts on your own computer. A script signed with it will not run on other computers.
- For MSIX, a self-signed certificate is useful for testing before you publish. Only users who install and trust your certificate can run the application.
- When you are ready to publish, Microsoft recommends a certificate issued by a trusted source, and explains that centralized trust adds levels of verification that protect users from malicious actors.
A use and misuse table
| Scenario | Self-signed OK? | Why |
|---|---|---|
| Developer testing on own machine | Yes | You control the trust decision |
| Internal test device lab | Yes, with care | You choose which machines trust it |
| Beta sent to outside testers | Poor choice | You are asking strangers to add a trust anchor |
| Public download | No | Users should not have to trust your certificate by hand |
| Production update channel | No | Weak identity, weak revocation story |
The hidden risk: trust you add to a machine
To install an MSIX signed with a self-signed certificate, Microsoft says the certificate must be imported into the Local Machine Trusted People store. It also warns that adding a certificate to local machine stores affects certificate trust for all users on that computer, and recommends removing such certificates when they are no longer needed so they cannot be used to compromise system trust.
That is a real security cost. A test certificate left installed on a shared machine, with its private key still on a developer laptop, is an open invitation. Anyone who gets the key can sign software that machine will trust.
If you must use one
- Create it for testing only, and name it clearly as a test certificate.
- For MSIX, make the certificate subject match the publisher in the package manifest.
- Protect the private key. Microsoft's guidance recommends strong key protection so malicious programs cannot sign on your behalf.
- Do not reuse the key for anything shipped.
- Remove the certificate from trust stores when the test ends.
- Never commit the exported key file or its password.
What to use instead
For release builds, use a certificate from a public authority or a managed signing service that keeps the key out of your hands, and plan renewal and timestamping from day one. See /resources/blog/where-to-keep-code-signing-keys-hardware-and-cloud-signing for storage options.
Where Safeguard fits
Trust anchors decide who may sign. Safeguard looks at what the signed software contains, with dependency scanning and SBOMs, and a free scan at gold.safeguard.sh/scan.
Quick check
Will a script signed with a self-signed certificate run on another PC?
Per Microsoft, no. It runs on the computer where the certificate is trusted, not on others.
Is it safe to leave a test certificate in the Trusted People store?
Microsoft recommends removing such certificates once they are no longer needed, because trust added to a machine store affects all users on that computer.
Sources
- Microsoft Learn: about_Signing
- Microsoft Learn: Create a certificate for package signing
- Microsoft Learn: Sign an MSIX package
Last reviewed: 19 October 2026.
