DigiCert breach: your certificates remain valid, watch out for fake renewals
By CaptainDNS
Published on November 6, 2026
Updated on November 6, 2026

Status as of November 6, 2026: on November 1, DigiCert published the full report on an incident affecting an internal system. Archived data supplied by its customers was accessed without authorization. According to the company, its certificates remain secure, valid and trusted. There is nothing to reissue for this incident, but document requests received by email call for caution.
- According to DigiCert's report, a small part of the customer archives was accessed: mainly business contact details and, for a small minority of customer accounts, personal documents, including identity documents.
- According to DigiCert, no certificate is affected: no TLS, VMC or CMC reissuance is needed because of this incident.
- CaptainDNS advice: don't send an identity document or follow a revalidation link received by email without independent verification.
What happened at DigiCert
On February 4, 2025, during an infrastructure migration, DigiCert moved this archiving system out of a VPN-only network segment. The system became reachable from outside, which was not intended. A sign-up function meant for other uses also ended up available there by mistake. Accounts created this way bypassed the multifactor authentication (MFA) that DigiCert otherwise requires and, although set to read-only, had access to archived data.
So the system had been exposed since February 2025, but DigiCert's investigation places the access to the data between June 27 and July 2, 2026.
DigiCert spotted the external accessibility in June 2026 and deployed an authorization fix on July 2, without knowing at that point that archives had been accessed. It began to suspect this access on October 12, then confirmed it on October 19, classifying it as a reportable event. A preliminary report followed on October 20 and the full report on November 1.
What data was accessed?
According to DigiCert, the incident involves only a small proportion of the archived data. Most of it is business contact information: names, business email addresses, phone numbers and business addresses.
A small minority of customer accounts also contained personal documents supplied by the customer: a driver's license, a passport, a utility bill or another document showing a name and address. So these documents include identity documents, but not only those.
The report gives no figures for the accounts or people concerned. A third party asked for these figures on November 5 in DigiCert's public incident record at Mozilla; as of November 6, DigiCert had not answered on this point.
Do you need to reissue a TLS, VMC or CMC certificate?
No, not because of this incident, based on the information DigiCert has published. Its report states that the certificate authority services, CertCentral and DigiCert ONE were not affected, and that customer login credentials and the certificates issued by DigiCert remain secure, valid and fully trusted. It counts zero affected certificates and specifies that customers have no action to take for their active certificates.
The access in question could not modify data in the archive system, approve a validation or issue a certificate. DigiCert also says it reviewed the logs of its certificate authority and its validations: none of them shows a validation, issuance or revocation associated with this account.
The report does not name VMCs or CMCs. Their continued trust follows from its general statement about the certificates issued by DigiCert, rather than from a sentence devoted to these two products. These conclusions remain DigiCert's own, in an incident record still open as of November 6. To choose and deploy these certificates, see our guide to VMC and CMC certificates for BIMI.
Your renewals follow their normal schedule. If a certificate has to be revoked for another reason, do so as planned. That leaves the question of the data: a passport or driver's license viewed by a third party is a problem for the person concerned, and no certificate reissuance changes that.
What should you do about a renewal email?
Identify internally who supplied documents to DigiCert and notify those people first. Having supplied documents does not mean they are among the data accessed.
The following advice comes from CaptainDNS, not from DigiCert, whose report mentions no phishing campaign. Our reasoning: accurate business contact details would make a fake renewal email more credible. If an unexpected message asks for supporting documents or offers a revalidation link, don't send the document and don't follow the link. Open the portal at the address you normally use, or reach support through a channel you already know, to confirm the request and how to send the document.
A document request can be legitimate. Check it through another channel, without refusing every revalidation on principle. For other warning signs, see how to spot a phishing email.
Why this is not another eMudhra
In the eMudhra incident and the certificates to replace, intermediates had weak keys, Chrome removed the emSign ECC Root CA - G3 root from its store and certificates had to be replaced. At DigiCert, customer archives were accessed, and the report counts no affected certificate. So October's instinct to replace certificates does not apply here.
FAQ
Do I need to replace my DigiCert TLS certificate?
No, not for this incident: according to DigiCert, no certificate is affected and no action is required for active certificates. Normal renewal schedules still apply.
Is my DigiCert VMC or CMC still valid?
Yes, according to DigiCert's general statement about the certificates it has issued. The report does not name VMCs or CMCs, but no replacement is needed because of this incident.
Has my identity document necessarily been exposed?
No. The report does not say that all customers or all documents are concerned: it refers to a small proportion of the archives and a small minority of customer accounts with personal documents. To find out about your own case, ask DigiCert through an official channel you already know.
Should I send an identity document again after a revalidation email?
Not on the strength of the message alone. First confirm the request through the usual portal or a support channel you already know, then send the document if the request is legitimate.
Sources: DigiCert's full report of November 1, 2026 (Mozilla ticket 2084460), a third party's question of November 5, 2026 in the same ticket and, for the comparison with eMudhra, Chrome Security blog post of October 20, 2026.


