What is the best practice using trusted signing for signing binaries

Reputation for Azure Artifact Signing (Trusted Signing) is primarily identity-based, not per-certificate. The current approach can be improved to better align with how SmartScreen and Artifact Signing are designed to work.

1. Best practice for using Public Trust vs Public Trust Test

• Public Trust Test certificate profiles are explicitly intended for inner-loop dev/test signing only and are not publicly trusted.
• Public Trust certificates are intended for any artifact that will be shared outside the inner dev/test loop, including pre-release builds that go to external testers.
• Recommended pattern:
  • Use Public Trust Test only for:
    • Local developer builds.
    • CI builds used strictly by engineering/QA in controlled environments where trust prompts are acceptable.
  • Use Public Trust for:
    • Any build that leaves the inner dev/test loop (public betas, external pilots, customer previews, production releases).
• Avoid re-signing the same binary with both Public Trust Test and Public Trust for external distribution. For reputation-building, only the Public Trust-signed artifacts matter on consumer endpoints.

2. How reputation is built (identity vs certificate)

• With Azure Artifact Signing, reputation is tied to the verified publisher identity, not to a specific long-lived certificate.
• Public Trust certificates are short-lived and issued from the same validated identity; reputation accumulates across builds signed under that identity.
• Using multiple Public Trust certificates under the same validated identity does not fragment reputation; they all contribute to the same publisher identity reputation over time.
• Public Trust Test certificates are not publicly trusted and include the lifetime EKU that forces validation to respect the certificate lifetime; they are not intended to build public SmartScreen reputation.

3. Strategies to maximize and accelerate reputation Within the documented behavior, there is no mechanism for an instant or manual SmartScreen reputation boost for consumer endpoints:

• SmartScreen reputation builds organically based on:
  • Download volume.
  • Clean install history across a wide audience.
• For new publishers, SmartScreen warnings for Public Trust-signed apps are expected for several weeks and typically require hundreds of clean installs before warnings subside.

Practical steps to optimize reputation growth:

• Sign all externally distributed builds with Public Trust under the same validated identity so all installs contribute to the same identity reputation.
• Minimize identity changes (publisher name, organization) that would reset or fragment reputation.
• Avoid unsigned external builds; unsigned binaries must build reputation from scratch per file hash.
• For enterprise/internal deployments:
  • Use Private Trust or enterprise distribution paths where SmartScreen may be bypassed or controlled by policy.
  • Enterprise admins can optionally submit files for review via the Microsoft Security Intelligence portal to accelerate trust for managed deployments.

4. Direct answers to the specific questions

• “Is this the best approach to maximize our opportunity to build reputation?”
  • Better approach: use Public Trust Test only for inner-loop dev/test; use Public Trust for any external or pre-production distribution so all external installs contribute to the same identity reputation.
• “Does reputation grow independently for each certificate or is it mainly our identity that both certificates are tied to that builds the reputation?”
  • Reputation is primarily tied to the verified publisher identity used by Azure Artifact Signing, not independently per Public Trust certificate. Public Trust Test profiles are not for public reputation.
• “Are there any ways to give our reputation a boost initially to avoid SmartScreen warnings?”
  • No supported way to bypass the initial SmartScreen warnings for new publishers on consumer endpoints. Reputation must build over time through sufficient download and clean install history. Enterprise admins can use internal distribution and optional file submission for managed environments, but this does not change the fundamental behavior for general consumer distribution.

References:

• Artifact Signing trust models
• Artifact Signing resources and roles
• Sign an MSIX package
• Sign your MSIX package: end-to-end guide
• SmartScreen reputation for Windows app developers