Do I need a code signing certificate to publish an MSIX to the Microsoft Store?

No. Microsoft's MSIX package requirements say you don't need a CA-trusted certificate, a .pfx file or a hardware token for a Store submission. After your app passes certification, the Store replaces any signature on the package with a Microsoft certificate.

Do I need a certificate to submit an EXE or MSI to the Store?

Yes. The installer and every Portable Executable file in it have to be signed with a certificate that chains up to a CA in the Microsoft Trusted Root Program. The Store doesn't re-sign EXE or MSI files.

Will users see a SmartScreen warning for my Store app?

Not for an app installed from the Store. Microsoft's SmartScreen page says Store apps are signed by a Microsoft certificate and are never subject to SmartScreen download warnings. Copies you hand out yourself, like a sideloaded .msix or a download from your site, are judged on their own signature and reputation.

Should I buy an EV certificate to avoid SmartScreen?

Microsoft says no. EV certificates used to start with positive SmartScreen reputation, but that's no longer the case, and Microsoft's page says paying extra for EV only to avoid SmartScreen warnings isn't justified anymore.

Is Azure Trusted Signing the same as Artifact Signing?

Yes. Microsoft renamed Trusted Signing to Artifact Signing. It's Microsoft's managed signing service for apps you distribute outside the Store, and you don't need it for an MSIX you only ship through the Store.

Can I sign the Store package with my own certificate anyway?

You can, and the Store will replace the signature. The catch is the Publisher. A Store package's Publisher has to match Product identity in Partner Center, and a signed package's Publisher has to match the certificate's subject, so a package signed with your own certificate usually carries the wrong Publisher for the Store.

Does StoreFast sign my package?

No. StoreFast uploads the .msix you give it to Partner Center as it is. Microsoft re-signs it after certification, like any Store submission.

Do you need a code signing certificate for the Microsoft Store?

Not for an MSIX. Microsoft re-signs every MSIX package with its own certificate after it passes certification, so you can submit one without buying a certificate. You do need one if you submit an EXE or MSI installer, if you install the package on your own machines to test it, or if you also hand it out outside the Store.

If you ship an MSIX only through the Store, skip the certificate. Buy one, or use Artifact Signing, when you submit an EXE or MSI or when you also distribute the app yourself.

An MSIX submitted to the Store needs no CA certificate, .pfx file or hardware token. The Store replaces the signature with a Microsoft one.
An EXE or MSI listing has to be signed with a certificate from a CA in the Microsoft Trusted Root Program, because the Store leaves those files alone.
A self-signed certificate is enough to install a test copy of your MSIX, as long as its subject matches the Publisher in your manifest.
Apps installed from the Store never get a SmartScreen download warning. Copies you distribute yourself do until they build reputation.

Who signs what

Feature	MSIX in the Store	EXE or MSI in the Store	Outside the Store
Your own certificate	Not neededMicrosoft re-signs it	Requiredfrom a Trusted Root Program CA	Requiredor users get warnings
Who signs the copy users install	Microsoft	You	You
SmartScreen download warning	Nocovered by Microsoft	Noinstalled from the Store	Until reputation buildseven when signed
Self-signed certificate works	For local testingnot needed for upload	No	Only where trustedeach machine has to trust it

MSIX packages in the Store

Microsoft's MSIX package requirements are direct about it. Your MSIX doesn't have to be signed with a certificate rooted in a trusted certificate authority when you submit it. The Store re-signs it with a Microsoft certificate during publishing, after it passes certification. You don't buy a certificate, you don't upload a .pfx or .cer file, and you don't need a USB token or HSM.

That's one of the reasons Microsoft lists for picking MSIX over an installer. If you're still deciding between the two, our guide to EXE or MSI vs MSIX compares them side by side.

What the Store does care about is the identity in your manifest. The Publisher attribute has to be the CN= value from Product identity in Partner Center. Many packaging tools take the Publisher from your signing certificate, so a package you signed yourself often ends up with your certificate's subject instead. If Partner Center rejects the upload for that, the package identity error guide shows where each value comes from.

EXE and MSI installers in the Store

Installers are different because the Store doesn't re-sign them. The MSI/EXE package requirements say the installer and all of its Portable Executable files have to be signed with a code signing certificate that chains up to a CA in the Microsoft Trusted Root Program. A self-signed certificate won't pass. Sign every new version before you upload it to its versioned URL.

Signing an MSIX to test it

Windows won't install an unsigned MSIX, so you need a signature to try your package before you submit it. Microsoft's guide to creating a package signing certificate says a self-signed certificate is fine for testing. Its subject has to match the Publisher in your manifest exactly. From an elevated PowerShell prompt, with your own Publisher value:

New-SelfSignedCertificate -Type Custom -KeyUsage DigitalSignature -CertStoreLocation "Cert:\CurrentUser\My" -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}") -Subject "CN=Contoso Software, O=Contoso Corporation, C=US" -FriendlyName "MyApp test signing"

Export it to a .pfx with Export-PfxCertificate, then import it into the Local Machine Trusted People store on each test machine so Windows trusts it. Microsoft suggests removing it from that store once you're done, since it affects trust for every user on the computer.

$password = ConvertTo-SecureString -String <password> -Force -AsPlainText
Export-PfxCertificate -cert "Cert:\CurrentUser\My\<thumbprint>" -FilePath test.pfx -Password $password
Import-PfxCertificate -CertStoreLocation "Cert:\LocalMachine\TrustedPeople" -Password $password -FilePath test.pfx

Then sign the package with SignTool from the Windows SDK. Always pass /fd with the hash algorithm the package was built with. MakeAppx uses SHA256 by default, and SignTool's own default is SHA1, which won't match.

SignTool sign /fd SHA256 /a /f test.pfx /p <password> MyApp.msix

If you set the manifest's Publisher to the Partner Center value and use that as the certificate subject, the same package works for testing and for upload. The Store throws your test signature away either way.

Distributing outside the Store

If you also offer the .msix or an installer on your own site, or deploy it inside a company, you sign it yourself with a certificate users' machines already trust. Microsoft's MSIX requirements page says so directly for sideloading and enterprise deployment.

For that, Microsoft recommends Artifact Signing, which was called Trusted Signing until it was renamed. It's a managed Azure service that keeps the keys in HSMs, so there's no token to plug in, and it works from GitHub Actions and Azure DevOps. A few things to know before you sign up:

Microsoft's SmartScreen page says it starts at $9.99 a month, and it needs a paid Azure subscription. Free, trial and sponsored subscriptions aren't supported.
Microsoft validates your identity first, which can take 1 to 20 business days for an organization. The quickstart lists the countries it's open to. Individual developers have to be in the United States or Canada.
You can't choose a custom CN or O. The certificate carries your validated legal name, so a package you sign with it needs a Publisher that matches that subject, which won't be the CN= value Partner Center gave your Store app. Plan on a separate build for outside the Store.
It doesn't issue EV certificates, and Microsoft says it has no plans to.

A certificate from any CA in the Trusted Root Program works too. Artifact Signing is Microsoft's own option, not a requirement.

SmartScreen and reputation

Microsoft's SmartScreen reputation page starts with the Store. Apps installed from it are signed by Microsoft and users never see a SmartScreen download warning for them. Everything else on the page applies to files you distribute yourself.

SmartScreen looks at two things, the reputation of the signing certificate's publisher and the reputation of the file's hash.
A file signed with a valid OV or EV certificate can still show an unrecognized app warning until it builds reputation, though it shows your verified publisher name.
A self-signed file gets the same "Windows protected your PC" warning as an unsigned one.
Reputation builds on its own from clean downloads. Microsoft says there's no exact threshold and that it can take several weeks and hundreds of installs. There's no way to submit a file for review on consumer machines.
Signing every release with the same certificate lets later versions benefit from the certificate's reputation. Unsigned files start from zero on every update.
EV certificates no longer skip the warning.

Where StoreFast fits

StoreFast doesn't sign anything and doesn't need your certificate. You drop the .msix you built on your app's page, StoreFast checks the package name and version against Partner Center, uploads the file as it is, writes What's new in every listing language and submits the update. Microsoft re-signs the package after certification, the same as when you upload it in Partner Center yourself.

StoreFast doesn't check the Publisher yet, so a package signed with the wrong subject can still be rejected by Partner Center. It handles MSIX updates only. EXE and MSI apps are coming, not available yet. Our guide to updating an MSIX app covers the rest of what an update needs.

Who it's for

StoreFast is a good fit if

You ship your app to the Store as an MSIX and want to stop doing updates by hand.
Your listing has several languages and you want What's new in all of them.
You release from GitHub Actions or a coding agent.

Look elsewhere if

You need a tool that signs packages for distribution outside the Store.
You submit an EXE or MSI installer by URL. That support is coming, not available yet.

Questions

Do I need a code signing certificate to publish an MSIX to the Microsoft Store?: No. Microsoft's MSIX package requirements say you don't need a CA-trusted certificate, a .pfx file or a hardware token for a Store submission. After your app passes certification, the Store replaces any signature on the package with a Microsoft certificate.
Do I need a certificate to submit an EXE or MSI to the Store?: Yes. The installer and every Portable Executable file in it have to be signed with a certificate that chains up to a CA in the Microsoft Trusted Root Program. The Store doesn't re-sign EXE or MSI files.
Will users see a SmartScreen warning for my Store app?: Not for an app installed from the Store. Microsoft's SmartScreen page says Store apps are signed by a Microsoft certificate and are never subject to SmartScreen download warnings. Copies you hand out yourself, like a sideloaded .msix or a download from your site, are judged on their own signature and reputation.
Should I buy an EV certificate to avoid SmartScreen?: Microsoft says no. EV certificates used to start with positive SmartScreen reputation, but that's no longer the case, and Microsoft's page says paying extra for EV only to avoid SmartScreen warnings isn't justified anymore.
Is Azure Trusted Signing the same as Artifact Signing?: Yes. Microsoft renamed Trusted Signing to Artifact Signing. It's Microsoft's managed signing service for apps you distribute outside the Store, and you don't need it for an MSIX you only ship through the Store.
Can I sign the Store package with my own certificate anyway?: You can, and the Store will replace the signature. The catch is the Publisher. A Store package's Publisher has to match Product identity in Partner Center, and a signed package's Publisher has to match the certificate's subject, so a package signed with your own certificate usually carries the wrong Publisher for the Store.
Does StoreFast sign my package?: No. StoreFast uploads the .msix you give it to Partner Center as it is. Microsoft re-signs it after certification, like any Store submission.

Publish your next MSIX update

Make your first submission in Partner Center, connect it to StoreFast and drop the next .msix on the page. Try it free for 7 days, no card needed.

Start your free trial See how it works

Sources

Facts about Microsoft's tools were checked against these pages on October 5, 2026.