SmartScreen reputation: distribution-feature-status.md contradicts smartscreen-reputation.md on whether certificate reputation carries across releases

[mortenbrudvik]

Type of issue

Outdated article

Feedback

Two articles in the same doc set, with the same ms.author (jken), make directly contradictory statements about whether SmartScreen reputation can be carried by a signing certificate. Developers deciding whether to buy a code signing certificate get opposite answers depending on which page they land on.

Page A — distribution-feature-status.md (ms.date: 2026-04-17, "Last reviewed: April 2026"), section "SmartScreen reputation: EV certificates no longer grant instant bypass":

SmartScreen reputation is now exclusively hash-based and accumulates over time, regardless of certificate type (OV or EV).

Current behavior: All non-Store, non-Microsoft-signed binaries show a SmartScreen prompt on first download until sufficient download history is accumulated for that file hash.

Page B — smartscreen-reputation.md (ms.date: 2026-05-04), which Page A links to "for full details":

SmartScreen evaluates two signals when a user downloads and runs a file:

1. Publisher reputation — Is the file signed? Is the signing certificate from a known, trusted publisher?
2. File hash reputation — Has this specific file been downloaded by users without indications of malicious behavior?

When a file is not signed, SmartScreen reputation must build for each new version of your files, starting with zero reputation. Reputation cannot transfer from previous versions unless both were signed using the same publisher identity.

New version: Signing files using a trusted certificate can allow certificate reputation to build, potentially avoiding warnings on new files signed by the same trusted certificate.

Why I believe Page B is the correct one and Page A is stale:

Both files were created in the same commit (8f8da71, 2026-04-17). Page B was then substantively revised in PR #5928 ("Revise SmartScreen reputation article for clarity and updates", merged 2026-05-05, described by its author as "Updated the SmartScreen reputation article for accuracy"). That PR specifically removed the sentence:

SmartScreen reputation is per file hash — every new build of your app starts with zero reputation. Reputation does not transfer from previous versions.

and replaced it with the "unless both were signed using the same publisher identity" wording. Page A still carries the pre-#5928 framing, because it has not been edited since 2026-04-17.

Page A's claim also conflicts with Microsoft Defender SmartScreen overview (ms.date: 2026-04-23), which states:

It also provides reputation checks for apps, checking downloaded programs and the digital signature used to sign a file. If a URL, a file, an app, or a certificate has an established reputation, users don't see any warnings.

Requested fix:

1. Update the "Current behavior" text in distribution-feature-status.md so it no longer says reputation is exclusively hash-based. Suggested rewording: keep the accurate part (EV no longer grants an instant bypass) and replace the "exclusively hash-based" sentence with a pointer to the two-signal model on smartscreen-reputation.md.
2. code-signing-options.md (ms.date: 2026-04-20) also appears to predate PR Revise SmartScreen reputation article for clarity and updates #5928 and carries the same framing in two places — "reputation accumulates per file hash over time" (OV certificates section) and "The same reputation-building model as OV certificates — new files will show a SmartScreen warning until they accumulate sufficient download history" (Azure Artifact Signing section). These read as though a certificate contributes nothing across releases, which contradicts Page B. Worth reconciling in the same pass.

The distinction is decision-relevant, not cosmetic: under Page A, a certificate never pays for itself outside the Store, so the rational choice is to ship unsigned. Under Page B, a consistent signing identity is the only reputation asset that compounds across releases, and shipping unsigned means every release restarts at zero. Independent developers are making purchasing decisions on this text.

Page URL

https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/distribution-feature-status

Content source URL

https://github.com/MicrosoftDocs/windows-dev-docs/blob/docs/hub/apps/package-and-deploy/distribution-feature-status.md

Author

John Kennedy (@GrantMeStrength)

Document Id

23d803ec-6f38-ca40-d6eb-f516adeef442