Issue with Microsoft SmartScreen and DigiCert

Microsoft Defender SmartScreen reputation is hash-based and behavior-based, not vendor-specific, and there is no supported mechanism to tie reputation changes to a particular CA incident or to request manual “whitelisting.” The available guidance for developers in this situation is limited to:

1. SmartScreen reputation model

• SmartScreen reputation for non-Store apps is based on the file hash and how commonly it is downloaded and run.
• Since 2024, EV and OV certificates are treated the same for SmartScreen; reputation accumulates per file hash over time, regardless of certificate type.
• All non-Store, non-Microsoft-signed binaries can show SmartScreen prompts on first download until sufficient reputation is built.
• Even with a long-standing certificate, new or re-signed binaries start with low reputation and must rebuild based on usage.

Relevant points from the platform behavior:

• EV certificates no longer grant an instant SmartScreen bypass; they follow the same reputation-building process as OV certificates.
• Reputation is not guaranteed to be permanent; changes in detection criteria, telemetry, or ecosystem signals can cause previously “quiet” binaries to start showing warnings again.

2. What Microsoft does and does not offer to developers

• Microsoft does not operate a formal “known list” or false-positive prevention program that developers can enroll in to avoid SmartScreen or Defender issues.
• The recommended practice is to sign all program files consistently with a certificate issued by a trusted root authority. This helps Microsoft’s systems recognize the publisher and may, over time, contribute to faster reputation building.
• For Defender detections (malware/PUA), the supported path is to submit the file as a software developer via Microsoft Security Intelligence and, if needed, use the developer contact form attached to the submission result to dispute the determination.
• For SmartScreen “not commonly downloaded” warnings specifically, Microsoft’s own guidance is to learn how SmartScreen works and allow reputation to build with continued distribution and usage.

3. Correlation with a specific CA incident

• The provided documentation does not state any link between a specific CA’s support portal incident and SmartScreen reputation resets or recalculations.
• There is no documented mechanism indicating that a non-revoked, still-valid OV certificate from a CA would automatically lose SmartScreen reputation due to that CA’s unrelated incident.
• The current guidance focuses on:
  • Using a certificate that chains to a trusted root in the Microsoft Trusted Root Program.
  • Understanding that SmartScreen reputation is per file hash and must be rebuilt when binaries change.

4. Practical options for developers in this situation Within the documented guidance, the actionable steps are:

• Continue consistent signing
  • Keep signing all binaries with the same, valid certificate that chains to a trusted root.
  • If reissuing the certificate (for operational or security reasons), continue to sign consistently with the new certificate going forward; SmartScreen will still build reputation per file hash.
• Use Store distribution where possible
  • For MSIX packages distributed via the Microsoft Store, Microsoft re-signs the package and Store-installed apps do not show SmartScreen warnings.
  • For MSI/EXE installers submitted through the Store, SmartScreen prompts do not appear during Store-based installation (though UAC prompts may still appear).
• For non-Store distribution
  • Expect SmartScreen prompts for new or newly re-signed files until reputation builds again.
  • Maintain stable installer filenames and signing patterns where feasible to avoid unnecessary hash changes.
• For Defender/SmartScreen issues beyond “unrecognized app”
  • If there is any malware or PUA detection, submit the affected files as a software developer through the Microsoft Security Intelligence portal and, if needed, use the developer contact channel attached to the submission result.

5. What developers cannot do

• Developers cannot:
  • Enroll in a special “trusted list” to bypass SmartScreen.
  • Request manual SmartScreen reputation resets or boosts for specific certificates or binaries.
  • Rely on EV certificates to avoid SmartScreen warnings; EV and OV are now equivalent for SmartScreen.

In summary, the documented and supported path is to:

• Ensure all binaries are properly signed with a certificate chaining to a trusted root.
• Continue distributing and having users run the software so SmartScreen reputation can rebuild per file hash.
• Use Microsoft Store distribution where feasible to avoid SmartScreen prompts.
• Use the Microsoft Security Intelligence submission and developer contact process only if there are actual malware/PUA detections, not just “unrecognized app” warnings.

References:

• SmartScreen reputation for Windows app developers
• Code signing options for Windows app developers
• Current status of Windows app distribution features
• Software developer FAQ
• Microsoft Security Advisory 2749655