DigiCert Data Breach Exposed ID Documents for Some Customers

DigiCert checks who you are before it puts your company's name inside a certificate. This week it started telling customers that the evidence they handed over for that check sat in a system an outsider could read. The certificates are fine, DigiCert says. The names, phone numbers and, for some people, passports behind them are another matter.

Key Takeaways

• DigiCert says an unauthorized account accessed archived customer data on an internal business system between June 27 and July 2, 2026.
• A February 4, 2025 infrastructure migration moved that system out of a VPN restricted network segment, and a self registration feature let outsiders create accounts that could read archived records.
• Names, business email addresses, phone numbers and business addresses were exposed, plus a driver's license, passport or utility bill for a small minority of customer accounts.
• DigiCert reports zero affected certificates and says its CA services, CertCentral and DigiCert ONE were not compromised, but it has not said how many people are affected.
• Certificate administrators named in the data are now likely targets for fake revalidation and renewal emails.

What Happened at DigiCert?

A network change exposed an internal business system, and an outsider used a self registration feature to get an account that could read its archive. DigiCert laid out the sequence in its incident report on Mozilla's Bugzilla, where certificate authorities disclose incidents to browser root programs.

The system stores information "customer representatives provide to us to validate their identity" and was meant to sit behind the VPN and MFA. On February 4, 2025, a migration moved it somewhere reachable from outside. DigiCert's root cause analysis says "the migration was treated as an infrastructure change rather than a security change," so nobody reviewed the new attack surface.

The key dates from the report:

• June 18, 2026: staff saw accounts that were not DigiCert's, wrongly concluded they had no data access and put the system behind a WAF.
• June 21 to June 24: a tip through DigiCert's managed security research program flagged external account creation, which DigiCert confirmed.
• June 27 to July 2: the data access window, closed by an authorization patch.
• October 12 to October 19: DigiCert first suspected archived data had been read, then confirmed it.
• October 24: self registration was switched off.

DigiCert's own lesson is blunt: "The incident was initially handled as an account-creation issue rather than a data-access event."

What Data Was Exposed in the DigiCert Breach?

Most exposed records hold business contact details, and a small minority also include a scanned identity document. DigiCert's notice, quoted by BleepingComputer, says the information "was limited to names, business email addresses, phone numbers, and business address," and that some records included a document "such as a driver’s license, passport, utility bill or other document."

Two early assumptions need correcting:

• These are personal documents, not company paperwork. The report describes documents showing a person's name and address, submitted by customer representatives. It does not name a validation product, so do not assume only EV customers are involved.
• Nobody outside DigiCert knows the count. The report says "This incident affected only a small proportion of archived data" and offers summary statistics only to root program representatives on request. DigiCert is still reviewing the documents before notifying those people.

Cloud architect Fabian Bader posted his letter and summed up the tone: "your data leak was 'limited' to only my full PII data."

Were Certificates or Private Keys Affected?

DigiCert says no certificates were affected, and its report does not mention private keys at all. It lists "Total number of certificates: 0" and says the account was read only, could not act as a validation approver and could not issue certificates. DigiCert also told BleepingComputer that "customer login credentials and issued certificates remain secure."

That answers the wrong question. The archive holds the inputs to identity validation: who your certificate contacts are, how to reach them and what their ID looks like. That is what an impersonator needs.

This is also the second time in 2026 that a "view only" DigiCert system leaked something useful. In April, a fake screenshot in DigiCert's support chat gave an attacker a read only support view that exposed initialization codes, and DigiCert revoked 60 code signing certificates. Read access was enough both times.

Why Should Email Users Care?

The exposed fields are a phishing kit for a narrow, valuable audience. A list of certificate administrators with their business emails, direct phone numbers and employers lets an attacker send a fake "your organization validation is expiring, upload a new ID" email that names the right person, at the right company, from a vendor they really use.

Real DigiCert breach letters are landing in inboxes now, so a lookalike asking you to "confirm your identity" fits right in. And requests for ID scans work: Revolut handed over passports to a requester writing from a government email domain earlier this year.

The timing gap matters too. DigiCert closed the access window on July 2 but confirmed it on October 19, 109 days later. Anyone who copied the data had a three month head start.

What Should DigiCert Customers Do Now?

Assume an attacker knows your certificate contacts, and harden the paths that trust them:

1. Never act on a DigiCert email link. Type the CertCentral address yourself to check orders, validation status or document requests.
2. Call back on a number you already have before sending any ID, approving a domain control check or changing a contact.
3. Brief everyone listed as a certificate contact or approver, and warn your help desk to expect impersonation calls using their names.
4. Review CertCentral users, approvers and API keys and remove anyone who no longer needs access, with MFA on every remaining account.
5. Publish CAA records (RFC 8659) naming the CAs allowed to issue for your domains, and watch Certificate Transparency logs for certificates you did not order.
6. If your ID was in the set, protect your credit. The FTC notes a credit freeze "is free to place or lift," and you need to contact all three bureaus.
7. Compliance teams: log it as a vendor incident. Ask your DigiCert account team which of your representatives' records were in scope, and record it in your vendor risk register.

What to Watch Next

The open questions sit in the Bugzilla thread: how many records were read, what tipped DigiCert off on October 12 and how the system connects to certificate validation. An audit confirming no business system server is still reachable from outside was due November 6. Until DigiCert publishes numbers, keep watching Certificate Transparency logs; October's ccTLD hijacks that yielded rogue Google certificates show why.