Microsoft Defender Removes Trusted DigiCert Root Certificates Worldwide

A faulty Microsoft Defender signature update deployed on April 30, 2026 has been flagging two legitimate DigiCert root CA certificates as Trojan:Win32/Cerdigent.A!dha, causing Microsoft Defender Antivirus to silently remove them from Windows AuthRoot certificate stores on affected machines. Microsoft issued a fix in Security Intelligence update 1.449.430.0, which also automatically restores previously deleted certificates.

Microsoft Defender DigiCert False Positive: Technical Details

The flawed detection was introduced in Security Intelligence update 1.449.424.0, released April 30, 2026. The update added a Trojan:Win32/Cerdigent.A!dha signature intended to target malicious or misissued certificates. Instead, the signature incorrectly matched the cryptographic thumbprints of two long-trusted DigiCert Public CA root certificates:

| Certificate Thumbprint | Status | |————————|——–| | 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43 | Incorrectly flagged and removed | | DDFB16CD4931C973A2037D3FC83A4D7D775D05E4 | Incorrectly flagged and removed |

When Defender detected these certificates, it removed them from the Windows AuthRoot certificate store at:

HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\

The AuthRoot store is the Windows system-level container for trusted root CA certificates. Any root CA entry removed from this store causes Windows to stop trusting all certificates issued under that CA hierarchy — even if the endpoint certificates themselves are valid and unexpired. In enterprise environments, this typically manifests immediately as HTTPS connection failures, code-signing validation errors, S/MIME email decryption failures, and broken authentication in any service presenting a DigiCert-issued TLS certificate.

There is no associated CVE number for this incident. This is a Defender signature false positive, not a vulnerability in Windows or in the DigiCert certificate infrastructure. DigiCert has not been breached; the certificates flagged are legitimate root CAs that have been in the Windows trust store for years.

Reports began surfacing on May 3, 2026, as administrators across Windows 11 and Windows Server environments started receiving Cerdigent threat detection alerts. In many cases, Defender was simultaneously alerting on and attempting to remediate a “threat” that was in fact the operating system’s own certificate infrastructure.

Exploitation and Threat Landscape

This is a false positive event, not active exploitation. No threat actor is involved. However, the operational impact is real and immediate: organizations running Microsoft Defender on Windows endpoints or servers may have had root CA certificates silently removed without administrator intervention, depending on their Defender quarantine policy configuration.

Wide distribution of the update across enterprise fleets means IT teams may encounter trust failures across a large number of systems simultaneously. Services that validate DigiCert-signed certificates — including financial platforms, SaaS vendors, internal PKI-dependent applications, and enterprise software — can fail for end users even when the remote server’s certificate is entirely valid. The failure mode looks identical to a certificate misconfiguration or a TLS negotiation failure, which can delay root cause identification.

Community reports noted that affected systems continued displaying Cerdigent detection alerts even after administrators attempted to quarantine or remove the flagged “threat,” because Defender was re-detecting the same legitimate certificate store entries that Windows itself relies on for system operations. The Microsoft Q&A forum was flooded with identical reports within hours of the update going wide.

Who Is Affected

Any Windows system running Microsoft Defender Antivirus that received Security Intelligence update 1.449.424.0 and has not yet applied 1.449.430.0 is potentially affected. This includes:

• Windows 10 and Windows 11 (consumer and enterprise editions)
• Windows Server editions with Defender Antivirus active
• Managed enterprise endpoints under any Microsoft Defender for Endpoint policy that permits automatic definition updates
• Azure Virtual Machines with Defender extensions enabled

Systems in air-gapped or restricted environments that manually distribute signature updates may have been exposed if administrators deployed the 1.449.424.0 definitions before the fix was available.

What You Should Do Right Now

• Update Defender definitions immediately. Navigate to Windows Security > Virus and threat protection > Protection updates > Check for Updates to pull Security Intelligence update 1.449.430.0 or later. On managed endpoints, force a definition update via Intune, WSUS, or your MDM platform. The fix automatically restores previously deleted certificates.

• Verify the Security Intelligence version fleet-wide. Run the following from an administrative PowerShell session:

“powershell Get-MpComputerStatus | Select-Object AntivirusSignatureVersion, AntivirusSignatureLastUpdated “

The version must read 1.449.430.0 or higher. Any endpoint showing 1.449.424.0 through 1.449.429.x should be considered affected.

• Confirm both DigiCert root certificates are present. After updating, verify the certs were restored:

“powershell $thumbprints = @( '0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43', 'DDFB16CD4931C973A2037D3FC83A4D7D775D05E4' ) foreach ($thumb in $thumbprints) { $cert = Get-ChildItem Cert:\LocalMachine\AuthRoot -ErrorAction SilentlyContinue | Where-Object { $_.Thumbprint -eq $thumb } if ($cert) { Write-Host "$thumb PRESENT" -ForegroundColor Green } else { Write-Host "$thumb MISSING — REMEDIATE" -ForegroundColor Red } } “

If either certificate remains missing after applying the fix, reimport it from DigiCert’s root CA repository or via Microsoft’s Certificate Trust List (CTL) automatic update service.

• Audit application and event logs for scope. In Event Viewer, check Windows Logs > Application and the Defender operational log at Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational for Cerdigent detection events. Use the timestamps to identify which endpoints removed the certificates and when.

• Notify downstream teams. If your organization operates services presenting DigiCert-issued TLS certificates — or relies on DigiCert-signed code for software deployment — alert helpdesk and network teams to correlate any reported HTTPS, authentication, or signing failures with this root cause before escalating as separate incidents.

• Check Windows Server instances separately. Server-side certificate stores may require explicit verification, particularly on IIS, Exchange, or other services where certificate changes directly affect service availability. Prioritize servers over workstations if resources are constrained.

Detection and Verification

To confirm Defender signature status and certificate presence across a fleet, use the following PowerShell one-liner compatible with remote execution via Invoke-Command:

# Run on each endpoint or via Invoke-Command -ComputerName
$status = Get-MpComputerStatus
$certs  = Get-ChildItem Cert:\LocalMachine\AuthRoot -ErrorAction SilentlyContinue
$missing = @(
  '0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43',
  'DDFB16CD4931C973A2037D3FC83A4D7D775D05E4'
) | Where-Object { $_ -notin ($certs | Select-Object -ExpandProperty Thumbprint) }

[PSCustomObject]@{
  Computer       = $env:COMPUTERNAME
  SigVersion     = $status.AntivirusSignatureVersion
  SigDate        = $status.AntivirusSignatureLastUpdated
  MissingCerts   = ($missing -join ', ') -or 'None'
}

Microsoft’s Security Intelligence update release notes confirm 1.449.430.0 as the remediated version. For Defender for Endpoint customers, the MDE portal’s Device health > Antivirus blade displays current definition versions across managed endpoints.

Conclusion

The Trojan:Win32/Cerdigent.A!dha false positive demonstrates how a single Defender signature update can silently break certificate trust chains across an entire enterprise fleet. Apply Security Intelligence update 1.449.430.0 immediately, verify both DigiCert root certificates are present in AuthRoot, and prioritize server-side certificate stores where trust failures carry the highest availability impact.