Fix Store eligibility: MSI/EXE apps can be published to the Store (#6677)

* Fix Store eligibility: MSI/EXE apps are Store-eligible via installer submission path

The packaging models table incorrectly showed both 'packaging with external
location' and 'unpackaged' as not Store-eligible (❌ No). In fact, the Microsoft
Store has two submission paths:
- MSIX submission: full Store management (updates, differential downloads, clean uninstall)
- MSI/EXE submission: Store hosts/distributes the installer; your installer handles the rest

Changes:
- At-a-glance table: external location → '✅ Yes (MSI/EXE submission)'; unpackaged same
- MSIX vs external location comparison table: updated Store eligible row
- Scenario table: removed 'The Store requires MSIX' (factually wrong); replaced with
  accurate description noting MSIX is recommended but MSI/EXE path exists
- Restored accidentally-dropped Enterprise/Intune scenario row
- Added MSI/EXE submission path link to both Indie dev and ISV scenario rows

Fixes feedback from jwmsft.

Co-authored-by: Copilot <[email protected]>

* Fix MSI/EXE Store signing: MSIX-only Store signing claims were incorrect

The Store has two submission paths with different signing requirements:
- MSIX submissions: Microsoft re-signs the package; no publisher cert needed
- MSI/EXE installer submissions: publisher must Authenticode-sign before submission

Files fixed:
- choose-distribution-path.md: 'App must be packaged as MSIX' → MSIX recommended,
  MSI/EXE path available (with note that publisher signing is still required)
- code-signing-options.md: intro para and 'no signing needed' section now correctly
  scope the free-signing claim to MSIX submissions; added NOTE about MSI/EXE
- publish-first-app.md: 'skip this step' for Store signing now correctly scoped to
  MSIX submissions; added explicit MSI/EXE signing requirement
- packaging/index.md: TIP about no cert needed scoped to MSIX Store submissions

Co-authored-by: Copilot <[email protected]>

* Address Copilot feedback and broken link in PR #6677

- packaging/index.md: clarify Unpackaged installer cell — 'XCopy / script' was
  misleading since MSI/EXE Store submission requires an actual MSI or EXE installer
  with silent install support
- packaging/index.md: replace 'won't get Store-managed updates' with precise wording:
  'the Store does not push updates to existing users — updates must be handled by
  the app or installer'
- publish-first-app.md line 155: fix broken link app-lifecycle → applifecycle
  (second occurrence; first was fixed in PR #6665)

Co-authored-by: Copilot <[email protected]>

* Fix choose-distribution-path table: split Store row, fix external location Store eligibility

- Split 'Microsoft Store' row into 'Microsoft Store (MSIX)' and 'Microsoft Store
  (MSI/EXE installer)' to accurately represent the two submission paths and their
  different signing/update behaviors
- Packaging with external location: ❌ No → ⚠️ Via MSI/EXE Store submission
- Unpackaged WinUI 3: aligned wording to match external location row
- Updated TIP callout: clarifies MSIX gets free signing/updates; MSI/EXE path also accepted
- Rewrote 'Microsoft Store' section intro to explain both submission paths

Resolves contradiction with packaging/index.md fix in same PR.

Co-authored-by: Copilot <[email protected]>

* Address Copilot feedback: specify CA/Trusted Root cert requirement for MSI/EXE Store submissions

Per the MSI/EXE app package requirements docs, Store installer submissions must
be signed with a cert issued by a CA in the Microsoft Trusted Root Program —
self-signed is explicitly not accepted. Several places said 'Authenticode signing'
which implies self-signed might be OK.

- publish-first-app.md: 'Authenticode-sign' → specify Trusted Root CA requirement;
  add link to MSI/EXE package requirements; fix link text 'diagnostics' → 'app lifecycle'
- code-signing-options.md: NOTE no longer implies Azure Artifact Signing is the
  only/required option; links to MSI/EXE package requirements instead
- choose-distribution-path.md: same Trusted Root CA clarification in requirements
- packaging/index.md: TIP clarifies CA/Trusted Root requirement for MSI/EXE

Co-authored-by: Copilot <[email protected]>

* Fix two more Copilot issues: telemetry link and MSI/EXE hosting description

- publish-first-app.md: 'Set up telemetry' bullet linked to app lifecycle page
  which isn't a telemetry resource; changed to Azure Application Insights link
- choose-distribution-path.md: 'Store hosts the installer' is factually wrong —
  publisher submits a versioned HTTPS URL pointing to their own CDN-hosted installer;
  the Store directs users to that URL (per app-package-requirements.md)

Co-authored-by: Copilot <[email protected]>

* Fix internal MSIX/MSI/EXE inconsistencies flagged by Copilot review

- code-signing-options.md: split 'Microsoft Store (signs for you)' table row
  into MSIX (free, Store re-signs) vs MSI/EXE (CA cert required) so the table
  doesn't imply Store signing is free for all submission paths

- choose-distribution-path.md:
  - 'Packaging with external location' What you don't get: 'Store eligibility'
    → now clarifies sparse package itself isn't submitted, but underlying
    installer can go via MSI/EXE Store path
  - Methods table: MSI/WiX/Inno Setup Store eligible ❌ → ⚠️ Via MSI/EXE
    Store submission
  - MSI/WiX/Inno Setup section text: 'not Store-eligible as primary packages'
    → 'not Store-eligible as MSIX packages, but can submit via MSI/EXE path'

- publish-first-app.md: auto-update table 'Microsoft Store' single row split
  into MSIX (automatic) vs MSI/EXE installer (manual, app handles updates)

Co-authored-by: Copilot <[email protected]>

* Fix MSI/EXE Store install flow description and split requirements links

- 'Store directs users to download' → 'Store downloads and runs the installer
  from that URL as part of the Store install flow' (users don't manually
  navigate to the CDN URL; Store handles the download)
- Requirements bullet: MSIX-only link → split into MSIX | MSI/EXE links
  since both paths have separate certification requirement pages

Co-authored-by: Copilot <[email protected]>

* Standardize Trusted Root Program cert wording across all 4 files

Copilot correctly noted that 'CA-issued cert from the Trusted Root Program'
is ambiguous. The official requirement (app-package-requirements.md) says
the installer must be 'signed with a certificate that chains up to a
certificate issued by a CA that is part of the Microsoft Trusted Root Program.'

Standardized to: 'certificate chaining to a CA in the Microsoft Trusted Root
Program' throughout choose-distribution-path.md, publish-first-app.md,
code-signing-options.md, and packaging/index.md.

Also fixed SmartScreen cell for MSI/EXE Store row in code-signing-options.md
table: 'Delivered via Store install experience' → 'No warnings (Store-vetted
install)' to match the format of other rows in the column.

Co-authored-by: Copilot <[email protected]>

* Fix 5 more Copilot issues (round 5)

- choose-distribution-path.md TIP: qualify 'no infrastructure to manage'
  as MSIX-only; MSI/EXE path requires publisher-hosted versioned HTTPS URL
- choose-distribution-path.md table: signing cell now says 'installer and
  all PE files' (not just installer) per MSI/EXE package requirements
- code-signing-options.md table: remove unsourced '~$10-300+/yr' cost range
  → 'varies by CA'; SmartScreen cell now says 'No SmartScreen prompts during
  Store install (UAC may still appear)' to distinguish from UAC
- packaging/index.md Unpackaged row: reorder Installer column to list
  'MSI or EXE installer' first (Store-relevant option), then XCopy/script
  for non-Store distribution — reduces confusion about Store eligibility

Co-authored-by: Copilot <[email protected]>

---------

Co-authored-by: Copilot <[email protected]>

Author: GrantMeStrength

hub/apps/package-and-deploy/choose-distribution-path.md

@@ -11,7 +11,7 @@ ms.localizationpriority: medium
 How you distribute your Windows app affects code signing costs, update mechanics, enterprise manageability, and how easily customers discover and install it. This article compares the main paths to help you make the right choice.
 
 > [!TIP]
-> **For most developers, the Microsoft Store is the recommended path.** It provides free code signing, built-in update delivery, broad discoverability, and a trusted install experience — with no infrastructure to manage.
+> **For most developers, the Microsoft Store is the recommended path.** It provides broad discoverability, a trusted install experience, and no infrastructure to manage for MSIX submissions (Microsoft re-signs and hosts the package). Win32 MSI/EXE installer submissions are also accepted — the publisher must host a versioned HTTPS installer URL — see [MSI/EXE app submission](/windows/apps/publish/publish-your-app/msi/create-app-submission). MSIX submissions get free code signing and built-in update delivery.
 
 > [!NOTE]
 > **If your app is built on web technologies** (HTML, JavaScript, CSS), a [Progressive Web App (PWA)](#progressive-web-app-pwa) is the fastest path to the Microsoft Store — no native packaging tools required.
@@ -20,27 +20,30 @@ How you distribute your Windows app affects code signing costs, update mechanics
 
 | Path | Best for | Code signing cost | Auto-update | Enterprise MDM | Distributed via Store |
 |---|---|---|---|---|---|
-| **Microsoft Store** | Consumer and business apps, broad reach | ✅ Free (Store signs for you) | ✅ Built-in | ✅ Via Intune with Company Portal | ✅ Yes |
+| **Microsoft Store (MSIX)** | Consumer and business apps, broad reach | ✅ Free (Store re-signs your package) | ✅ Built-in | ✅ Via Intune with Company Portal | ✅ Yes |
+| **Microsoft Store (MSI/EXE installer)** | Existing Win32 apps with own installer | 💲 Publisher must sign the installer and all PE files with a cert chaining to the [Microsoft Trusted Root Program](/security/trusted-root/participants-list) | ❌ Manual (app or installer handles updates) | ✅ Via Intune with Company Portal | ✅ Yes |
 | **PWA (Progressive Web App)** | Web apps and web-based experiences | ✅ Free (Store signs for you) | ✅ Via Store or browser | ✅ Via Intune with Company Portal | ✅ Yes |
 | **MSIX sideload (enterprise)** | Internal LOB apps via Intune/ConfigMgr | 💲 Azure Artifact Signing (formerly Trusted Signing) (~$10/mo) or self-signed + Intune cert profile | ✅ Via App Installer file or MDM | ✅ Native | ❌ No |
 | **MSIX direct download (ISV)** | Commercial apps sold from your own site | 💲 CA-trusted cert required ([Azure Artifact Signing (formerly Trusted Signing)](/azure/trusted-signing/) recommended) | ✅ Via `.appinstaller` file | ⚠️ Limited | ❌ No |
-| **Packaging with external location** | Existing apps with own installer needing Windows features | 💲 Same as MSIX direct download | ✅ Your existing mechanism | ⚠️ Limited | ❌ No |
-| **Unpackaged WinUI 3** | Niche: enterprise without MSIX capability, or max install simplicity | 💲 Cert recommended for SmartScreen | ❌ Manual only | ⚠️ Limited (via Intune/ConfigMgr Win32 deployment) | ⚠️ Limited (Store-listed installer submission) |
+| **Packaging with external location** | Existing apps with own installer needing Windows features | 💲 Same as MSIX direct download | ✅ Your existing mechanism | ⚠️ Limited | ⚠️ Via MSI/EXE Store submission (publisher signing required) |
+| **Unpackaged WinUI 3** | Niche: enterprise without MSIX capability, or max install simplicity | 💲 Cert recommended for SmartScreen | ❌ Manual only | ⚠️ Limited (via Intune/ConfigMgr Win32 deployment) | ⚠️ Via MSI/EXE Store submission (publisher signing required) |
 
 ## Microsoft Store (recommended)
 
-Publishing to the Microsoft Store is the most complete distribution solution for Windows apps.
+Publishing to the Microsoft Store is the most complete distribution solution for Windows apps. Two submission paths are available:
 
-**What you get:**
-- Code signing handled automatically — no certificate purchase needed
-- Built-in update delivery with staged rollout support
+- **MSIX submission** — recommended for new apps and WinUI 3 apps. Microsoft re-signs the package; no cert purchase needed. Includes Store-managed updates, staged rollouts, and differential downloads.
+- **MSI/EXE installer submission** — for existing Win32 apps with their own installer. Publisher submits a versioned HTTPS URL to the installer hosted on the publisher's own CDN; the Store downloads and runs the installer from that URL as part of the Store install flow. Publisher must sign the installer with a certificate chaining to a CA in the [Microsoft Trusted Root Program](/security/trusted-root/participants-list). Updates are the app's responsibility.
+
+**What you get (both paths):**
 - Discovery through the Store's search and curated collections
-- Trusted install UX with no SmartScreen warnings
+- Trusted install UX
 - Revenue processing, refunds, and analytics included
+- Enterprise deployment via Intune with Company Portal
 
 **Requirements:**
-- App must be packaged as MSIX (WinUI 3 apps are packaged by default)
-- App must pass [Store certification requirements](/windows/apps/publish/publish-your-app/msix/app-package-requirements)
+- MSIX is the recommended package format — WinUI 3 apps are packaged by default. Win32 apps with an existing MSI or EXE installer can also submit via the [MSI/EXE installer path](/windows/apps/publish/publish-your-app/msi/create-app-submission) (note: MSI/EXE submissions require a certificate chaining to a CA in the [Microsoft Trusted Root Program](/security/trusted-root/participants-list) — self-signed is not accepted; Store-managed updates are not available for this path)
+- App must pass Store certification requirements: [MSIX requirements](/windows/apps/publish/publish-your-app/msix/app-package-requirements) | [MSI/EXE requirements](/windows/apps/publish/publish-your-app/msi/app-package-requirements)
 - Developer account required ([Partner Center](https://partner.microsoft.com/dashboard))
 
 **When to choose this:**
@@ -141,7 +144,7 @@ If you have an existing app with its own installer (WiX, NSIS, InstallShield) an
 - Your existing install and update mechanism stays in place
 
 **What you don't get:**
-- Store eligibility
+- Direct MSIX Store submission (the sparse package is not itself Store-submitted; however, your underlying installer can be submitted via the [MSI/EXE Store installer path](/windows/apps/publish/publish-your-app/msi/create-app-submission))
 - The clean install/uninstall model of full MSIX
 
 **When to choose this:**
@@ -184,7 +187,7 @@ Many Windows apps are distributed using ClickOnce, MSI, WiX, Inno Setup, or simi
 | **MSIX via Store** | ✅ Built-in | ✅ Free (Store signs) | ✅ Yes | Most apps — recommended starting point |
 | **MSIX + .appinstaller** | ✅ Built-in | 💲 CA-trusted cert | ❌ No | ISVs distributing directly from a website |
 | **ClickOnce** | ✅ Built-in | 💲 Cert recommended | ❌ No | WPF/WinForms apps; not supported for WinUI 3 |
-| **MSI / WiX / Inno Setup** | ⚠️ Manual or custom | 💲 Cert recommended | ❌ No | Apps with complex install requirements or existing installer |
+| **MSI / WiX / Inno Setup** | ⚠️ Manual or custom | 💲 Cert recommended | ⚠️ Via MSI/EXE Store submission (see below) | Apps with complex install requirements or existing installer |
 | **Self-contained EXE (xcopy/zip)** | ❌ None | 💲 Cert recommended | ❌ No | Simple utilities; developer/power-user audiences |
 | **winget manifest** | ✅ Via winget | 💲 Cert recommended | ❌ No | Any of the above — adds discoverability via `winget install` |
 
@@ -200,7 +203,7 @@ ClickOnce is **not supported for WinUI 3 apps**. Use MSIX with `.appinstaller` f
 
 Traditional EXE and MSI installers remain common for Windows apps with complex installation requirements (driver installation, system services, registry configuration). Tools like [WiX Toolset](https://wixtoolset.org/), [Inno Setup](https://jrsoftware.org/isinfo.php), and [NSIS](https://nsis.sourceforge.io/) are community-maintained and widely used. Update support requires your own implementation.
 
-These formats are not Store-eligible as primary distribution packages. However, you can combine them with [packaging with external location](../desktop/modernize/grant-identity-to-nonpackaged-apps-overview.md) if you need package identity for specific Windows features.
+These formats are not Store-eligible as MSIX packages, but can be submitted to the Store via the [MSI/EXE installer path](/windows/apps/publish/publish-your-app/msi/create-app-submission) (requires a certificate chaining to a CA in the [Microsoft Trusted Root Program](/security/trusted-root/participants-list) and a silent-install capable installer). You can also combine them with [packaging with external location](../desktop/modernize/grant-identity-to-nonpackaged-apps-overview.md) if you need package identity for specific Windows features.
 
 ### Self-contained EXE (xcopy deployment)
 

hub/apps/package-and-deploy/code-signing-options.md

@@ -8,22 +8,26 @@ ms.localizationpriority: medium
 
 # Code signing options for Windows app developers
 
-If you publish your app through the Microsoft Store, code signing is free and handled for you automatically — you don't need to purchase or manage a certificate. Everything in this article applies to apps distributed **outside the Microsoft Store**.
+If you publish your app as an **MSIX package** through the Microsoft Store, code signing is free and handled for you automatically — Microsoft re-signs the package after certification and you don't need to purchase or manage a certificate. If you publish as an **MSI/EXE installer** through the Store, you are responsible for Authenticode signing your installer before submission. Everything else in this article applies to apps distributed **outside the Microsoft Store**.
 
 ## Comparison at a glance
 
 | Option | Cost | Availability | SmartScreen behavior | Store eligible | Best for |
 |---|---|---|---|---|---|
-| **Microsoft Store** (signs for you) | Free | Worldwide | ✅ No warnings | ✅ Yes | Recommended for most developers |
+| **Microsoft Store (MSIX)** — Store re-signs your package | Free | Worldwide | ✅ No warnings | ✅ Yes | Recommended for most new apps |
+| **Microsoft Store (MSI/EXE installer)** — publisher must sign | Cert chaining to [Trusted Root Program CA](/security/trusted-root/participants-list) required (varies by CA) | Worldwide | ✅ No SmartScreen prompts during Store install (UAC may still appear) | ✅ Yes | Existing Win32 apps submitting via MSI/EXE installer path |
 | **Azure Artifact Signing** (formerly Trusted Signing) | ~$9.99/month | Organizations: USA, Canada, EU, UK. Individuals: USA and Canada only | ⚠️ Reputation builds over time; initial warnings expected | ❌ No | Recommended for non-Store distribution |
 | **OV certificate** (from a CA such as DigiCert, Sectigo) | $150–300/year | Worldwide | ⚠️ Same as Azure Artifact Signing — reputation builds over time | ❌ No | Developers who can't use Azure Artifact Signing, or who prefer traditional CAs |
 | **EV certificate** | $400+/year | Worldwide | ⚠️ Same as OV since 2024 — no longer instant bypass | ❌ No | No longer recommended specifically for SmartScreen bypass |
 | **Self-signed certificate** | Free | — | ❌ Blocks installation for public users | ❌ No | Dev/testing only, or enterprise with managed certificate trust |
 | **No signature** | Free | — | ❌ Strong SmartScreen block; enterprises may block entirely | ❌ No | Not recommended for public distribution |
 
-## Microsoft Store — no signing needed
+## Microsoft Store — MSIX submissions: no signing needed
 
-Publishing through the Microsoft Store is the recommended distribution path for most Windows apps. Microsoft re-signs your package automatically, meaning users never see a SmartScreen warning and you never need to purchase or renew a certificate.
+Publishing an **MSIX package** through the Microsoft Store is the recommended distribution path for most Windows apps. Microsoft re-signs your package automatically, meaning users never see a SmartScreen warning and you never need to purchase or renew a certificate.
+
+> [!NOTE]
+> If you're submitting a **Win32 MSI or EXE installer** to the Store (rather than an MSIX package), Microsoft does not re-sign your installer. The installer and its PE files must be signed with a certificate chaining to a CA in the [Microsoft Trusted Root Program](/security/trusted-root/participants-list) — self-signed certificates are not accepted. See [App package requirements for MSI/EXE](/windows/apps/publish/publish-your-app/msi/app-package-requirements).
 
 Create a free developer account at [storedeveloper.microsoft.com](https://storedeveloper.microsoft.com). After you register, use [Partner Center](https://partner.microsoft.com/dashboard) to submit your app and manage its listing.
 

hub/apps/package-and-deploy/packaging/index.md

@@ -41,9 +41,9 @@ For more information, see [Features that require package identity](../../desktop
 
 | Model | Package identity | Installer | Store eligible | Best for |
 |---|---|---|---|---|
-| **Packaged (MSIX)** | ✅ Yes | MSIX replaces installer | ✅ Yes | New apps, Store publishing, enterprise MDM |
-| **Packaging with external location** | ✅ Yes | Your existing installer | ❌ No | Existing apps with own installer, ISVs |
-| **Unpackaged** | ❌ No | XCopy / script | ❌ No | Internal tools, dev utilities, simple scenarios |
+| **Packaged (MSIX)** | ✅ Yes | MSIX replaces installer | ✅ Yes (MSIX submission) | New apps, Store publishing, enterprise MDM |
+| **Packaging with external location** | ✅ Yes | Your existing installer | ✅ Yes (MSI/EXE submission) | Existing apps with own installer, ISVs |
+| **Unpackaged** | ❌ No | MSI or EXE installer (also: XCopy or script for non-Store distribution) | ✅ Yes (MSI/EXE submission — requires an MSI or EXE installer with silent install support) | Broad Win32 distribution, internal tools |
 
 ### Packaged apps (MSIX)
 
@@ -63,7 +63,7 @@ This is the sweet spot for existing Win32/WPF/WinForms apps that ship via their
 |---|---|---|
 | Replaces your installer | Yes | No |
 | Binaries inside the package | Yes | No (external) |
-| Store eligible | Yes | No |
+| Store eligible | Yes (MSIX submission) | Yes (MSI/EXE submission) |
 | Package identity | Yes | Yes |
 | Update mechanism | MSIX update | Your existing mechanism |
 
@@ -82,13 +82,13 @@ Before you commit to unpackaged, check the [features table above](#features-that
 
 | Scenario | Recommended model | Details |
 |---|---|---|
-| **Indie developer publishing to the Microsoft Store** | Packaged (MSIX) | The Store requires MSIX. WinUI 3 apps are packaged by default — no changes needed. **Code signing is handled free by the Store.** → [Distribute your packaged app](../../distribute-through-store/how-to-distribute-your-win32-app-through-microsoft-store.md) |
+| **Indie developer publishing to the Microsoft Store** | Packaged (MSIX) recommended | MSIX is the recommended path — it enables Store-managed updates, differential downloads, and clean uninstall. WinUI 3 apps are packaged by default. **Code signing is handled free by the Store.** → [Distribute your packaged app](../../distribute-through-store/how-to-distribute-your-win32-app-through-microsoft-store.md)<br><br>Win32 apps with an existing MSI or EXE installer can also publish to the Store via the [MSI/EXE submission path](../../publish/publish-your-app/msi/create-app-submission.md), but the Store does not push updates to existing users — updates must be handled by the app or installer. |
 | **Enterprise app deployed via Intune or Configuration Manager** | Packaged, or external location for existing installers | New apps should use MSIX. Existing apps with their own installer can use packaging with external location. **Code signing:** use a self-signed cert (trusted via Intune, Group Policy, or Configuration Manager) or [Azure Artifact Signing (formerly Trusted Signing)](/azure/trusted-signing/). → [Deploy packaged apps](../../windows-app-sdk/deploy-packaged-apps.md) |
-| **ISV shipping a direct download with own installer** | Packaging with external location | Register a lightweight identity package alongside your existing installer. **Code signing:** a CA-trusted certificate is required for non-Store distribution. [Azure Artifact Signing (formerly Trusted Signing)](/azure/trusted-signing/) is the recommended lower-cost option. → [Grant package identity](../../desktop/modernize/grant-identity-to-nonpackaged-apps-overview.md) |
+| **ISV shipping a direct download with own installer** | Packaging with external location | Register a lightweight identity package alongside your existing installer. **Code signing:** a CA-trusted certificate is required for non-Store distribution. [Azure Artifact Signing (formerly Trusted Signing)](/azure/trusted-signing/) is the recommended lower-cost option. → [Grant package identity](../../desktop/modernize/grant-identity-to-nonpackaged-apps-overview.md)<br><br>Alternatively, submit your existing installer to the Store via the [MSI/EXE submission path](../../publish/publish-your-app/msi/create-app-submission.md). |
 | **Internal tool or developer utility** | Unpackaged | Simplest to build and deploy. The Windows App SDK works via NuGet, but some features won't be available. |
 
 > [!TIP]
-> **Not sure about code signing costs?** Publishing through the Microsoft Store means you don't need to separately obtain or manage a certificate for end-user trust. For other distribution paths, your signing approach depends on deployment context — enterprise environments can trust a self-signed certificate through device management, while broader non-Store distribution typically requires a CA-trusted code signing solution. [Azure Artifact Signing (formerly Trusted Signing)](/azure/trusted-signing/) is Microsoft's recommended option (see [pricing](https://azure.microsoft.com/pricing/details/trusted-signing/)), with no hardware token required.
+> **Not sure about code signing costs?** Publishing an **MSIX package** through the Microsoft Store means you don't need to separately obtain or manage a certificate for end-user trust — Microsoft re-signs the package. Publishing a **Win32 MSI/EXE installer** through the Store requires a certificate chaining to a CA in the [Microsoft Trusted Root Program](/security/trusted-root/participants-list); self-signed is not accepted. For other distribution paths, your signing approach depends on deployment context — enterprise environments can trust a self-signed certificate through device management, while broader non-Store distribution typically requires a CA-trusted code signing solution. [Azure Artifact Signing (formerly Trusted Signing)](/azure/trusted-signing/) is Microsoft's recommended option (see [pricing](https://azure.microsoft.com/pricing/details/trusted-signing/)), with no hardware token required.
 
 ## Framework-dependent vs self-contained deployment