Nvidia Code Signing Certificates Stolen by Ransomware Group: How to Protect Yourself

Code signing certificates are digital certificates that establish the authenticity and integrity of software: they prove that an executable came from the identified publisher and has not been modified since signing. When attackers steal code signing certificates and the private keys that produce their signatures, the consequences extend far beyond the original breach victim. Any malware signed with stolen certificates will appear to operating systems and security software as if it originated from the legitimate publisher, bypassing security warnings and endpoint controls that protect millions of users. In February 2022, a ransomware group attacked Nvidia and reportedly exfiltrated code signing certificates used to sign drivers for Nvidia’s GPUs. Security researchers subsequently observed the stolen certificates being used to sign malware, confirming that stolen certificates become active weapons immediately after exfiltration. The recommended action: store all code signing private keys in FIPS 140-3 validated Hardware Security Modules (HSMs) that prevent private key extraction, implement automated certificate lifecycle management with short certificate lifetimes, and enforce code signing validation in all CI/CD pipelines. For broader context on how certificate theft fits into ransomware attacks, see Decrypting Ransomware: Understanding How Cybercriminals Hold Your Data Hostage. For code signing solutions, see CodeSign Secure.

Quick Answer: Why Is Code Signing Certificate Theft Severe?

Stolen code signing certificates and private keys enable attackers to sign malware that appears to come from a legitimate, trusted publisher. Operating systems and endpoint security tools use code signing to determine whether to allow software to execute, whether to display security warnings, and whether to allow drivers and kernel modules to load. Malware signed with a stolen certificate from a trusted publisher bypasses these controls and is accepted as legitimate by both the operating system and security software. This means that millions of users who rely on a vendor’s software can be exposed to attacker-signed malware without any visible indication that the software is malicious.

Nvidia Code Signing Certificates Theft: A Wake-Up Call for Robust Security Measures

The theft of code signing certificates from Nvidia highlights the vulnerability of digital certificates and the critical importance of securing the private keys that produce their signatures. Nvidia is a leading GPU manufacturer whose software and drivers are used globally for computing, gaming, professional visualization, and data center workloads. With the theft of its code signing certificates, attackers could sign and distribute malware that appears to be legitimate Nvidia software, with potential consequences for every individual and organization using Nvidia products.

Incident Timeline and Impact Assessment

The attack against Nvidia occurred in February 2022. The Lapsus$ group claimed responsibility, stating they had access to employee information and had exfiltrated significant data from Nvidia. Among the exfiltrated data were code signing certificates and their associated private keys used to sign Nvidia’s GPU drivers. The stolen certificates were not the only data exfiltrated: the incident involved a substantial data breach affecting both employee information and proprietary technical data.

Security researchers observed that threat actors subsequently used the stolen Nvidia certificates to sign malware samples, demonstrating that the certificates were actively misused after the theft. This confirmed the worst-case consequence of code signing certificate theft: the certificates became tools for attacker operations rather than remaining solely in the hands of the legitimate publisher. The incident served as a direct, publicly documented example of the supply chain risk that certificate theft creates for every organization that distributes software.

Timeline	Event
February 2022	Ransomware group attacks Nvidia; exfiltrates code signing certificates, private keys, and over 1 TB of data
February-March 2022	Lapsus$ group publicly claims responsibility and attempts to leverage exfiltrated data
March 2022	Security researchers identify malware samples signed with the stolen Nvidia certificates, confirming active misuse
Ongoing	Stolen certificates remain a supply chain risk; certificate revocation limits new trust establishment but does not retroactively invalidate already-signed and deployed malware

What Are Code Signing Certificates?

Code signing certificates are digital certificates issued by trusted certificate authorities (CAs) and used to sign software executables, drivers, scripts, and firmware. When code signing is used to sign software, it provides two assurances to the verifying system: that the software came from the identified publisher (because the signature was produced with the publisher’s private key), and that the software has not been modified since it was signed (because any modification to the signed content invalidates the signature).

Code signing certificates typically include the publisher’s name, a timestamp, and a unique serial number. During installation, the user’s computer verifies the digital signature against the certificate authority’s public key to confirm authenticity. Operating systems use code signing to determine whether to display a security warning when software is installed, whether to allow unsigned software to run in high-security environments, and whether kernel drivers meet integrity requirements for loading. The trust model only holds as long as the private key corresponding to the certificate is held exclusively by the legitimate publisher.

The Risks of Stolen Code Signing Certificates

The theft of code signing certificates combined with their private keys has serious consequences that extend well beyond the immediate breach victim:

• Malware that passes signature validation: With a stolen certificate and its private key, an attacker can sign any malicious executable and have it validate as authentic against the stolen certificate’s chain. Operating system security, endpoint protection, and application whitelisting controls that rely on code signing trust the signed malware.
• Driver-level access: Code signing certificates used to sign kernel drivers provide the highest level of trust in Windows and other operating systems. Malware signed with a stolen driver certificate can be loaded as a kernel driver with the full trust of the operating system, enabling attacks that bypass user-space security controls entirely.
• Broad impact across all users of the certificate holder’s software: Every user and organization that relies on software from the certificate holder is potentially exposed. The attack surface is not limited to the original breach victim; it extends to every endpoint that could receive attacker-signed software masquerading as legitimate updates.
• Revocation limitations: Certificate revocation stops future trust establishment for new certificates issued with the compromised key, but does not retroactively invalidate malware that has already been signed and deployed before revocation. Systems that have already installed attacker-signed software before revocation are not automatically protected by revocation after the fact.
• Long-lived certificates compound the risk: Code signing certificates with multi-year validity periods remain usable by attackers for the duration of their validity period even after the breach is discovered, unless revocation is performed immediately and revocation is enforced by all relying systems.

How to Protect Yourself from Code Signing Certificate Theft

Protecting against code signing certificate theft requires both preventive controls that prevent private key exfiltration and detective controls that identify unauthorized signing operations. The following checklist addresses both layers:

1. Store Private Keys in FIPS 140-3 Validated HSMs

   Hardware Security Modules (HSMs) provide tamper-resistant storage for private keys and enforce access controls that prevent private key extraction. A FIPS 140-3 Level 3 or higher validated HSM ensures that even an attacker with full administrative access to the HSM host system cannot extract the private key material. All code signing private keys should be generated inside the HSM and never exported in a form that would allow extraction. For scalable HSM-based signing, see HSM-as-a-Service.

2. Verify Certificate Authenticity Before Trusting Software

   When installing software, verify the authenticity of the code signing certificate by checking the publisher’s name against the expected publisher, confirming the certificate chain validates to a trusted root CA, checking the certificate revocation status to confirm the certificate has not been revoked, and verifying that the timestamp is consistent with the claimed build date. Any mismatch in these elements may indicate that the certificate has been compromised or that the software is not from the claimed publisher.

3. Enforce Multi-Factor Authentication for Signing Operations

   Multi-factor authentication adds an additional security layer to signing operations by requiring more than one authentication method before a signing key can be used. Even if an attacker compromises a developer’s credentials, MFA prevents unauthorized use of the signing key without access to the second factor. This control applies both to human signing operations and to automated CI/CD pipeline signing processes, which should use hardware tokens or HSM-backed service accounts rather than credential-based authentication.

4. Implement Least-Privilege Access for Signing Keys

   Only the specific processes and identities required for code signing operations should have access to signing keys. Developers, build servers, and deployment pipelines should have the minimum access required for their specific function. Signing key access should be logged with full audit trails including what was signed, the identity that requested the signing operation, and the timestamp. Anomalous signing operations, such as signing outside normal business hours or signing executables not matching expected file types, should trigger immediate alerts.

5. Monitor for Suspicious Activity and Unauthorized Signing

   Implement continuous monitoring of all signing operations with detailed audit logging. Certificate Transparency (CT) logs provide public visibility into all certificates issued under your organization’s domains and can reveal unauthorized certificate issuance. Security information and event management (SIEM) systems should alert on unexpected signing volumes, signing of unexpected file types, signing operations from unexpected systems, and any attempt to export or access private key material.

Update Log

Date	Update
February 2022	Ransomware group attacks Nvidia; code signing certificates and private keys exfiltrated
March 2022	Security researchers confirm stolen certificates used to sign malware samples
April 2023	Original blog post published covering the incident and protection recommendations
September 2026 (this update)	Content updated with incident timeline table, impact assessment, expanded risk analysis, prioritized protection checklist, update log, FAQ section, and additional internal links

Conclusion

By proactively protecting code signing certificates and the private keys that produce their signatures, organizations can help mitigate the risks that incidents like the Nvidia breach demonstrate. The central lesson is that certificate security is only as strong as private key security: if the private key can be exfiltrated, the certificate becomes a tool for attackers rather than a trust signal for defenders. Storing private keys in FIPS 140-3 validated HSMs, enforcing MFA and least-privilege access for signing operations, implementing continuous monitoring of signing activity, and using short certificate lifetimes with automated renewal are the foundational controls that prevent code signing certificates from becoming attack vectors. For organizations managing code signing at scale, CodeSign Secure provides the infrastructure for HSM-backed signing with full audit trails and automated certificate lifecycle management. For the broader context of ransomware and how certificate theft fits into attacker operations, see Decrypting Ransomware: Understanding How Cybercriminals Hold Your Data Hostage.

Frequently Asked Questions

What are code signing certificates and what do they prove?

Code signing certificates are digital certificates issued by trusted CAs and used to sign software executables, drivers, scripts, and firmware. They prove two things: that the software came from the identified publisher (because the digital signature was produced with the publisher’s private key), and that the software has not been modified since signing (because any modification invalidates the signature). Operating systems use code signing to determine whether to display security warnings, whether to allow software to run in restricted environments, and whether drivers meet kernel integrity requirements.

What happened in the Nvidia code signing certificate theft?

In February 2022, a ransomware group attacked Nvidia and exfiltrated data including code signing certificates and their private keys used to sign Nvidia’s GPU drivers. The Lapsus$ group claimed responsibility. Security researchers subsequently observed the stolen certificates being used to sign malware, confirming that the certificates were actively misused after the theft. The incident demonstrated that stolen code signing certificates become immediate attack tools for adversaries.

Why is the theft of code signing private keys more serious than theft of the certificates alone?

A certificate without its private key cannot produce new signatures; it can only validate signatures already produced. A private key with a corresponding valid certificate can produce any number of new signatures, each validating as if produced by the legitimate certificate holder. This is why private keys must be stored in FIPS 140-3 validated HSMs that prevent extraction even by administrators with access to the HSM host system.

How do you protect code signing certificates and private keys from theft?

Store all private keys in FIPS 140-3 validated HSMs that provide tamper-resistant storage and prevent key extraction. Enforce MFA for all signing operations. Implement least-privilege access so only authorized processes and identities can invoke signing keys. Monitor all signing operations with detailed audit logging. Use short-lived certificates with automated renewal to limit exposure windows. Enforce code signing validation in CI/CD pipelines.

What should an organization do if their code signing certificates are compromised?

Immediately revoke the compromised certificates through the issuing CA. Generate new key pairs for replacement certificates in an HSM, never reusing the compromised key pair. Re-sign all software signed with the compromised certificate and release updated versions to distribution channels. Notify customers and security communities. Investigate how private key material was exfiltrated. Review all signing operations performed with the compromised certificate to identify any malicious signatures produced before discovery.