SmartScreen Reputation Reset Following EV Certificate Renewal — Requesting Engineering Review

Question

SmartScreen Reputation Reset Following EV Certificate Renewal — Requesting Engineering Review

Devender Prakash 5

Dear Microsoft SmartScreen & Windows Defender Application Reputation Team,

I am reaching out regarding a SmartScreen reputation issue that is impacting our software distribution — one that I believe warrants immediate attention from your engineering team rather than a standard support response.

The situation is straightforward: we renewed our EV code signing certificate. Same organization, same publisher name, same Certificate Authority — nothing changed except the certificate thumbprint as part of a routine renewal. Yet SmartScreen has effectively treated us as an unknown publisher, resetting years of established reputation overnight.

This is not a new software vendor. Our products have been deployed across enterprise environments for years without a single security incident. The SmartScreen warning our customers are now seeing is, in every practical sense, a false positive — and it is causing real damage to customer confidence and our distribution pipeline.

I understand how SmartScreen's reputation model works — it is tied to the certificate thumbprint, not the publisher identity. That architectural decision makes sense for catching bad actors. But it creates an unreasonable burden on legitimate, long-standing publishers who go through a standard certificate renewal. There needs to be a resolution path for this scenario, and I am asking you to help us find it.

Specifically, I need answers to the following:

Reputation Transfer — Is there a process to link or transfer the reputation built under our previous EV certificate to our renewed one, given that the publisher identity and CA are unchanged? If not, why not, and what is the escalation path to make this happen?
Reputation Threshold Transparency — What exactly does our renewed certificate need to reach before warnings are suppressed? I am not looking for a general answer. I need the specific scoring factors: unique machine downloads, install confirmation rates, geographic distribution, time windows — whatever goes into that calculation. We need to know what we are working toward.
Real-Time Monitoring — Is there a publisher portal or any mechanism through which we can track our current reputation standing? If not, this is a significant gap for enterprise publishers managing large software portfolios.
Resolution Without Binary Submission — Given our established history, I am asking whether reputation restoration can be handled based on publisher verification alone, without requiring binary-level submission. Specifically:
- Can our Certificate Authority liaise directly with your team to validate the continuity of our publisher identity?

Thanks,

Devender Prakash

0 comments

3 answers

Your answer

Answer 1

The accepted answer here is machine-generated and cites nothing, so here are the actual sources.

A Microsoft employee answered the same question in April, for an OV renewal with a new key: "the existing reputation does not carry over and even long-standing publishers can see the 'Windows protected your PC' warning until the new certificate and signed binaries accumulate enough real-world download and execution telemetry", and "there is no manual whitelisting, no fast-track for small publishers, and no direct SmartScreen contact channel beyond the supported submission workflows" (https://learn.microsoft.com/en-us/answers/questions/5857071/how-can-a-small-software-publisher-build-smartscre). That is the answer to questions 1, 3 and 4: no transfer, no portal, no CA liaison.

Why it works this way, since Daedalus asked. Reputation is attached to the specific certificate, not to the company name, and it has been since 2010: "Reputation is assigned to the specific certificate that a developer or ISV uses to sign their code, not the certificate issuer." The reason is that reputation goes both ways. If your certificate signs malware, the certificate loses its reputation, not the file alone. So from SmartScreen's side a new key is a new identity, and it cannot tell your routine renewal from someone who registered the same company name and bought a certificate. It does not read the CA's paperwork. It counts downloads.

Why it feels new for EV specifically: it used to be handled. Microsoft's 2012 announcement of EV code signing said EV certificates "have a unique identifier which makes it easier to maintain reputation across certificate renewals" (https://learn.microsoft.com/en-us/archive/blogs/ie/microsoft-smartscreen-extended-validation-ev-code-signing-certificates). That identifier was the EV OID, and the Trusted Root Program removed EV code-signing OIDs from its roots in August 2024 and now treats "all Code Signing certificates equally" (https://learn.microsoft.com/en-us/security/trusted-root/program-requirements, section 3.D.3). So the renewal continuity EV buyers were promised in 2012 went away with the OID, and nobody announced that part.

One question back, because it is the only unknown left. Did your renewal generate a new key pair, or reuse the old one? Microsoft's confirmed case is new-key. I have not seen anyone report what happens on a same-key renewal, in either direction. If yours kept the key and still reset, that is worth knowing.

I put the whole thing, with Microsoft's wording on what resets reputation and what does not help, here: https://signalscreen.dev/blog/smartscreen-warning-signed-installer

Answer 2

Daedalus Tech P/L 0

So essentially, based on the AI response here, we just have to “let it build a reputation score” and all will be well?

Groovy. So we pay hundreds of dollars for a renewed EV certificate every year when the previous one expires, make zero changes to the binary other than signing it with the renewed certificate, and Microsoft’s response is effectively just: “wait and see”?

This is a low-volume commercial application. It relies on the relatively small number of users who download and run it in order to generate revenue, including the revenue that pays for said EV certificate.

If renewing a certificate resets the reputation Microsoft has already built for the exact same publisher and exact same software, then low-volume developers are placed in a position where we may spend a significant portion of every certificate lifecycle rebuilding reputation from scratch.

Microsoft — can you explain to me like I’m five why business owners should consider that acceptable, and what security benefit is actually achieved by discarding established publisher reputation purely because a routinely renewed certificate has a new thumbprint?

This just sounds like Microsoft putting something relatively simple into the "too hard basket" because it requires just a little lateral thinking.

Rob Koch 26,070 Reputation points Volunteer Moderator

2026-09-07T21:03:50.6833333+00:00

I believe the portion referenced in the following document referenced within the AI Answer states the current status clearly, though the fact that it wasn't triggered until the certificate renewal implies that Microsoft had not forced this new action until certificate renewal occurred, allowing pre-existing certificate holders such as yourself a grace period to consider switching to the now preferred distribution method of the Microsoft Store.

Current status of Windows app distribution features - Windows apps | Microsoft Learn

Since I'm not a developer myself, I only learned of this change to the operation of EV Certificates when answering another small developer's question a few weeks ago, though it didn't affect him, but both the more general document I found at the time and the section of the one I referenced above made this new treatment for EV certificates clear, so it appears that only Store distribution receives this ability going forward.

I'm not aware how Microsoft distributes this sort of change information to developers, but I assume they likely had, since I've personally seen very few such specific complaints which implies that at least most developers had become aware before certificate renewal, or possibly that far more of them had switched to the Store method even before this change in operation occurred.

Rob

Answer 3

Reputation transfer after EV certificate renewal There is no supported process to manually transfer or merge SmartScreen reputation from an old certificate to a renewed one, even when:

The organization and publisher name are unchanged
The same CA is used
Only the thumbprint has changed as part of renewal

SmartScreen reputation is based on:

Publisher reputation: tied to the specific signing certificate
File hash reputation: tied to each individual binary

When a new certificate is used, SmartScreen treats it as a new publisher identity for reputation purposes. Reputation must build organically again for files signed with the new certificate. There is no documented escalation path or engineering-side override to “restore” or “clone” reputation between certificates.

For non-Store distribution, the only supported mitigation is to:

Continue signing all releases with the new certificate
Allow reputation to accumulate over time from real-world downloads and clean usage

Reputation thresholds and scoring factors SmartScreen does not publish exact thresholds, scoring formulas, or detailed telemetry requirements. The available guidance is intentionally high-level:

Reputation builds based on download volume and behavior for each file hash
For new apps or new binaries, users may see “unrecognized app” warnings initially
Warnings stop once the file hash has “sufficient download history” without malicious indicators
This can take “several weeks and hundreds of clean installs from a wide audience”

No official documentation exposes:

Exact counts of unique machines
Required geographic distribution
Specific time windows
Weighting of install confirmations vs. blocks

Only the following is documented:

Reputation is hash-based and publisher-based
Reputation for a certificate can help future files signed with the same identity
EV vs OV no longer changes SmartScreen behavior; EV certificates no longer grant instant bypass

Real-time monitoring or publisher portal There is no documented publisher portal or API that exposes SmartScreen reputation scores or status for:

Certificates
Individual file hashes

For consumer endpoints, SmartScreen reputation is opaque by design. The only observable behavior is whether a given download or execution triggers a warning.

Enterprise admins have limited additional options (for internal deployments only), such as:

Distributing from trusted intranet locations that may bypass SmartScreen checks
Submitting files for review via the Microsoft Security Intelligence portal to accelerate trust for internal/managed environments

But even in those cases, there is no real-time “reputation dashboard” for publishers.

Resolution without binary submission / via CA The documented model is:

Reputation builds organically from signed binaries being downloaded and used without malicious or unwanted behavior
There is no general “known list” or false-positive-prevention enrollment program that can be joined to pre-approve a publisher or certificate

Specifically:

Microsoft does not accept files or publishers into a standing “known list” program on request
The recommended path is to sign programs consistently with a certificate from a trusted root authority so that reputation can be inferred over time
In rare cases, a publisher certificate may itself be added to a trusted list, but this is not something that can be requested or forced; it is an internal outcome of Microsoft’s analysis

There is no documented mechanism for:

A CA to liaise with the SmartScreen team to restore or transfer reputation between certificates
Restoring SmartScreen reputation purely on the basis of publisher verification, without file-level reputation building

If a specific binary is being incorrectly classified as malicious or unwanted (beyond “not commonly downloaded” warnings), the supported path is:

Submit the file via the Microsoft Security Intelligence portal as a software developer
Wait for a determination
If the result is unsatisfactory, use the developer contact form associated with the submission to dispute the determination

Practical steps to minimize impact going forward Within the documented constraints, the following practices help reduce SmartScreen friction over time:

Sign every release with a consistent identity (avoid changing certificates unnecessarily)
Do not modify binaries after signing, to avoid breaking signatures
Avoid signing any binaries that exhibit malicious or potentially unwanted behavior, as this can create negative reputation for the certificate
Communicate with customers and early adopters that new versions may show SmartScreen prompts initially, and instruct them to verify the publisher name and source before proceeding
For enterprise customers, consider:
- Distribution via Microsoft Store where feasible (Store apps are re-signed by Microsoft and are not subject to SmartScreen download warnings)
- Using trusted intranet distribution points and enterprise SmartScreen policies to reduce prompts in managed environments

There is no supported way to bypass the reputation-building phase for a renewed EV certificate or to obtain internal scoring details. The only documented and supported path is to continue signing with the new certificate and allow SmartScreen reputation to rebuild organically.

References: