DigiCert screensaver breach: what it means for code signing and malware defense

A file that looked like a routine support attachment ended up testing one of software security’s most important assumptions: that signed code is safer code.

According to the incident description documented at Mozilla, a threat actor contacted DigiCert’s support team through a customer chat channel on April 2, 2026, and sent a ZIP file disguised as a customer screenshot. Inside was a malicious .scr executable, a Windows screensaver file format that can also run code . After support systems were compromised, the attackers obtained initialization codes for a limited number of code-signing certificates, and some of those certificates were used to sign malware .

How the attack unfolded

The initial tactic was straightforward social engineering. Help Net Security described the lure in similar terms: a ZIP file made to look like a customer screenshot but containing a malicious Windows screensaver file .

SecurityWeek reported that the malware infected two endpoints. One was identified on April 3, and another on April 14 . From a compromised system, the attackers reportedly pivoted into an internal support portal . That mattered because authenticated DigiCert support analysts could use a limited function to move into customer accounts; SecurityWeek said that access included specific functions such as initialization codes for pending certificates .

BleepingComputer also described the scope as limited, but specified that the exposed initialization codes related to previously approved, not-yet-delivered EV code-signing certificates .

Why EV code-signing certificates are valuable to attackers

Code signing is meant to help verify where software came from and whether it has been altered. DigiCert, as a certificate authority, plays a major role in internet communications and software distribution, and its code-signing certificates are used by software developers .

That is why this was more than a routine support compromise. The attackers were able to abuse a trust mechanism. ThreatNoir reported that some of the obtained code-signing certificates were used to sign malware . CyberInsider similarly described a case in which compromised internal support systems and certificate issuance data were abused to obtain valid EV code-signing certificates, with some later used to sign malware .

EV, or Extended Validation, certificates are designed to carry extra trust. That trust can be turned against defenders. Vectra has described the broader pattern: threat actors can use EV certificates to sign malicious files and exploit the higher trust often associated with EV-signed applications; organizations that rely only on signature-based trust remain exposed .

What the reports do — and do not — show

The available sources describe compromised support endpoints, internal support functions and access to initialization codes . They do not show that DigiCert root keys or CA keys were compromised.

That distinction matters. A root or CA key compromise would be a different and more severe class of incident. The known reporting instead points to abuse of a support and certificate issuance process around code-signing certificates, not a full takeover of DigiCert’s certificate authority infrastructure .

How large was the impact?

The public figures vary because sources appear to be counting different things:

• ThreatNoir referred to a limited number of code-signing certificates, with some used to sign malware .
• Risky Business reported 27 stolen code-signing certificates that were later used to sign malware .
• ThreatLocker said 60 code-signing certificates were revoked in total .

Those numbers should not be treated as interchangeable. Obtained certificates, abused certificates and revoked certificates are different categories. Even so, the incident was significant because only a small number of valid-looking code-signing certificates can help malware appear more trustworthy during delivery and detection .

Containment: revocation and cancelled orders

DigiCert revoked the identified certificates within 24 hours of discovery and set the revocation date back to the certificates’ issuance date, according to BleepingComputer . Pending orders in the affected window were also cancelled as a precaution . ThreatNoir reported the same broad containment steps: affected certificates were revoked within 24 hours and pending orders in the relevant time window were cancelled .

Revocation reduces future abuse, but it does not end the work for defenders. Security teams still need to evaluate suspicious signed files using certificate details, hashes, behavior and threat-intelligence context, because attackers can deliberately use EV signatures as a trust shortcut .

The extra complication: Microsoft Defender false positives

The DigiCert incident also coincided with confusion around Microsoft Defender alerts. BleepingComputer reported that Microsoft Defender incorrectly flagged DigiCert certificates as Trojan:Win32/Cerdigent.A!dha . Daily.dev summarized that Defender began incorrectly flagging legitimate DigiCert root certificates after a signature update on April 30; Microsoft later issued Security Intelligence update 1.449.430.0, which fixed the detection and restored removed certificates .

For organizations, that created a practical incident-response problem: teams had to separate real certificate abuse, possible alerts on malware signed with misused certificates, and false positives against legitimate DigiCert certificates .

What security teams should take away

The lesson is not that code signing is useless. It is that code signing should never be the only basis for trust.

Practical steps include:

• Treat signatures as evidence, not proof. A valid or EV-based signature should not automatically make a file trusted; attackers can weaponize EV certificates to sign malicious files .
• Check certificate details. Issuer, serial number, certificate chain, timestamp and revocation status matter when a signed binary looks suspicious. In the DigiCert case, revocation and backdating the revocation date to the issuance date were central containment steps .
• Give behavior more weight. Process activity, persistence mechanisms, network connections and sandbox results should be evaluated alongside the signature, because signed malware is designed to exploit trust .
• Treat support and admin portals as high-risk systems. Even limited support features can become security-critical if they provide access to customer accounts or certificate initialization codes .
• Have a false-positive process. Certificate alerts are not automatically proof of infection; legitimate DigiCert root certificates were reportedly misidentified by Defender and later restored through a Microsoft update .

Bottom line

The DigiCert screensaver incident was limited in the available reporting, but it hit a sensitive part of the software trust chain. Attackers did not need to compromise root or CA keys to create risk; abusing support workflows and EV code-signing certificates was enough to make malware look more legitimate . For modern malware defense, a digital signature should inform the decision — not make it.