Pre-publish accuracy fix: Azure Artifact Signing naming consistency (#6652)

All references to 'Azure Trusted Signing' updated to 'Azure Artifact
Signing (formerly Trusted Signing)' across four files to match the
authoritative naming used in msix-pr reference files (sign-msix-
package-guide.md, msix-troubleshooting-guide.md).

Files updated:
- choose-distribution-path.md (5 instances)
- smartscreen-reputation.md (6 instances including table cell and heading)
- distribution-feature-status.md (1 instance in related content)
- packaging/index.md (3 instances including TIP block)

URLs (/azure/trusted-signing/) unchanged — correct regardless of
display name.

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

Author: GrantMeStrength

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

@@ -18,8 +18,8 @@ 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 |
-| **MSIX sideload (enterprise)** | Internal LOB apps via Intune/ConfigMgr | 💲 Azure 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 Trusted Signing](/azure/trusted-signing/) recommended) | ✅ Via `.appinstaller` file | ⚠️ Limited | ❌ No |
+| **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 |
 
 ## Microsoft Store (recommended)
@@ -55,7 +55,7 @@ For internal line-of-business apps that will be deployed to managed devices via
 - Full package identity and access to Windows features (notifications, background tasks, etc.)
 
 **Code signing:**
-- Use [Azure Trusted Signing](/azure/trusted-signing/) (~$10/month) for a CA-trusted certificate, or
+- Use [Azure Artifact Signing (formerly Trusted Signing)](/azure/trusted-signing/) (~$10/month) for a CA-trusted certificate, or
 - Use a self-signed certificate deployed to endpoints via Intune Trusted Certificate profiles
 
 **Requirements:**
@@ -81,7 +81,7 @@ For commercial apps sold directly from your website (not through the Store), you
 
 **Code signing:**
 - A CA-trusted code signing certificate is required — users cannot install unsigned or self-signed MSIX packages without trusting the cert manually
-- [Azure Trusted Signing](/azure/trusted-signing/) (~$10/month) is Microsoft's recommended option: no hardware token required, integrates with CI/CD pipelines
+- [Azure Artifact Signing (formerly Trusted Signing)](/azure/trusted-signing/) (~$10/month) is Microsoft's recommended option: no hardware token required, integrates with CI/CD pipelines
 - Traditional OV certificates are also accepted (typically $150–300/year from a CA)
 
 **SmartScreen:** New certificates accumulate SmartScreen reputation over time based on download volume. Expect some SmartScreen prompts for new releases. See [SmartScreen reputation for Windows app developers](smartscreen-reputation.md).
@@ -127,4 +127,4 @@ Many Windows apps are distributed using MSI, WiX, Inno Setup, ClickOnce, or simi
 - [SmartScreen reputation for Windows app developers](smartscreen-reputation.md)
 - [Current status of Windows app distribution features](distribution-feature-status.md)
 - [Publish to the Microsoft Store](/windows/apps/publish/)
-- [Azure Trusted Signing](/azure/trusted-signing/)
+- [Azure Artifact Signing (formerly Trusted Signing)](/azure/trusted-signing/)

hub/apps/package-and-deploy/distribution-feature-status.md

@@ -119,4 +119,4 @@ The `MsixPackaging@1` task in Azure DevOps pipelines uses MSBuild 4.8.4161.0 (in
 - [SmartScreen reputation for Windows app developers](smartscreen-reputation.md)
 - [App Installer file overview](/windows/msix/app-installer/app-installer-file-overview)
 - [Auto-update and repair apps](/windows/msix/app-installer/auto-update-and-repair--overview)
-- [Azure Trusted Signing](/azure/trusted-signing/)
+- [Azure Artifact Signing (formerly Trusted Signing)](/azure/trusted-signing/)

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

@@ -83,12 +83,12 @@ 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) |
-| **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 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 Trusted Signing](/azure/trusted-signing/) is the recommended lower-cost option. → [Grant package identity](../../desktop/modernize/grant-identity-to-nonpackaged-apps-overview.md) |
+| **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) |
 | **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 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 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.
 
 ## Framework-dependent vs self-contained deployment
 

hub/apps/package-and-deploy/smartscreen-reputation.md

@@ -36,7 +36,7 @@ Historically, Extended Validation (EV) code signing certificates granted **immed
 | Self-signed | ❌ Strong block — cert not trusted by default; same behavior as unsigned |
 | OV certificate (Organization Validated) | ⚠️ Warning — app flagged as unrecognized until reputation accumulates; publisher name is displayed as verified |
 | EV certificate (Extended Validation) | ⚠️ Warning — same as OV for new files (no longer instant bypass) |
-| Azure Trusted Signing certificate | ⚠️ Warning for new files; reputation accumulates normally |
+| Azure Artifact Signing (formerly Trusted Signing) certificate | ⚠️ Warning for new files; reputation accumulates normally |
 | Microsoft Store | ✅ No warning — covered by Microsoft's certificate |
 
 EV certificates still provide value (they require more identity validation, which may matter for enterprise procurement), but they no longer provide instant SmartScreen bypass. Paying a premium for EV solely to avoid SmartScreen warnings is no longer justified.
@@ -47,9 +47,9 @@ EV certificates still provide value (they require more identity validation, whic
 
 Apps published through the Microsoft Store are re-signed by Microsoft and carry full reputation. Users will never see a SmartScreen warning for a Store-installed app.
 
-### Azure Trusted Signing
+### Azure Artifact Signing (formerly Trusted Signing)
 
-[Azure Trusted Signing](/azure/trusted-signing/) is Microsoft's recommended code signing service for non-Store distribution:
+[Azure Artifact Signing (formerly Trusted Signing)](/azure/trusted-signing/) is Microsoft's recommended code signing service for non-Store distribution:
 
 - **Cost:** Approximately $10/month — significantly lower than traditional CA certificates
 - **No hardware token required** — integrates directly with CI/CD pipelines (GitHub Actions, Azure DevOps)
@@ -60,7 +60,7 @@ Apps published through the Microsoft Store are re-signed by Microsoft and carry
 
 Traditional code signing certificates from Certificate Authorities (DigiCert, Sectigo, etc.) are also accepted. OV certificates typically cost $150–300/year; EV certificates $400+/year. Both now have equivalent SmartScreen behavior for new files.
 
-If you already have an OV or EV certificate, it remains valid and functional. If you're purchasing a new certificate, Azure Trusted Signing is typically the better choice for Windows app distribution.
+If you already have an OV or EV certificate, it remains valid and functional. If you're purchasing a new certificate, Azure Artifact Signing (formerly Trusted Signing) is typically the better choice for Windows app distribution.
 
 ## What to expect when you publish a new app
 
@@ -78,13 +78,13 @@ There is no way to manually submit a file for SmartScreen reputation review for
 - **Publish to the Microsoft Store** where feasible — this is the most reliable way to avoid warnings entirely
 - **Sign every release** — unsigned files show a stronger SmartScreen warning than signed files, and enterprises may block unsigned binaries entirely
 - **Use a consistent signing identity** — changing your signing certificate affects the publisher trust signal; note that each new build's hash also starts with no file reputation regardless of certificate continuity
-- **Use Azure Trusted Signing** for non-Store distribution — it's cost-effective and integrates with automated build pipelines
+- **Use Azure Artifact Signing (formerly Trusted Signing)** for non-Store distribution — it's cost-effective and integrates with automated build pipelines
 - **Communicate with early adopters** — for new apps, let beta users know they may see a SmartScreen prompt on first download, and that they should only proceed after verifying the publisher and confirming they trust the download source
 
 ## Related content
 
 - [Choose a distribution path for your Windows app](choose-distribution-path.md)
 - [Current status of Windows app distribution features](distribution-feature-status.md)
 - [Sign an app package using SignTool](/windows/msix/package/sign-app-package-using-signtool)
-- [Azure Trusted Signing documentation](/azure/trusted-signing/)
+- [Azure Artifact Signing (formerly Trusted Signing) documentation](/azure/trusted-signing/)
 - [Microsoft Trusted Root Program requirements](/security/trusted-root/program-requirements)