SmartScreen Reputation Reset Following EV Certificate Renewal — Requesting Engineering Review

Devender Prakash 5 Reputation points
2026-05-23T14:35:14.0466667+00:00

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:

  1. 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?
  2. 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.
  3. 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.
  4. 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

Microsoft Security | Microsoft Defender | Other
0 comments

3 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-05-23T14:35:41.93+00:00
    1. 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
    1. 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
    1. 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.

    1. 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
    1. 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:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

    1 person found this answer helpful.
  2. Daedalus Tech P/L 0 Reputation points
    2026-09-07T06:32:14.0833333+00:00

    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.

    Was this answer helpful?

  3. Andrey Mn 0 Reputation points
    2026-09-10T08:24:23.8166667+00:00

    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

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.