Identity

DigiCert, the public certificate authority (CA), has disclosed that an outsider read part of an internal archive holding information customers gave it to prove their identity. Most of the exposed records are business contact details: names, business email addresses, phone numbers and business addresses of customer representatives. A small minority of accounts also held an uploaded document such as a driver's license, passport or utility bill.

DigiCert says no certificates or issuance systems were touched, and that customers do not need to replace active certificates. The data that did leak is still useful to an attacker: it names the people who request and approve certificates at each customer, which makes them a ready list for phishing and for social engineering aimed at certificate validation. If anyone at your organization went through DigiCert organization or extended validation, assume their contact details may be in the set.

How it happened

DigiCert published its full incident report on Mozilla's Bugzilla tracker on November 1, the channel root programs (the browser and OS vendors that decide which CAs to trust) require CAs to use. The cause was a network change with no security review behind it.

On February 4, 2025, the business system was moved from a VPN-restricted network segment to a different availability zone during an infrastructure migration. That move made it reachable from the internet. The system sits on an account manager platform that DigiCert also uses for customer-facing products, and that platform ships with an optional self-registration flow meant for customer sign-up elsewhere. The flow came along to the internal instance.

Three gaps then lined up:

• Accounts created through self-registration were not subject to the multi-factor authentication (MFA) DigiCert requires of staff. MFA only switched on for accounts assigned to an application that required it.
• New accounts got read-only mode by default and no application. The authorization model assumed an account with no application could see nothing. It could in fact read archived data.
• Nobody was alerting on new account creation through the external endpoint or on request volume from internal endpoints, because monitoring was never revisited after the migration.

DigiCert's root cause analysis says the migration was handled as an infrastructure change rather than a security change, so the review that would have caught the new attack surface never ran.

Detection and the slow second look

On June 18, 2026, DigiCert staff noticed accounts on the system that did not belong to DigiCert. The reviewer concluded they had no data access because no application was assigned, and the system was put behind a web application firewall (WAF) that blocked new external sign-ups. On June 21 a report arrived through DigiCert's managed security research program pointing at the same account creation path, and engineers reproduced it on June 24.

The data was read between June 27 and July 2. DigiCert's patch, released July 2, made internal endpoints validate the account manager's token and return HTTP 401 to any account with no assigned application. That closed the hole, but at the time DigiCert did not know anything had been read. On July 9 the WAF limited the system's hostnames to VPN traffic apart from approved endpoints.

DigiCert first suspected data access on October 12 and confirmed it on October 19, using retained logs and audit tables to rebuild the access window and match file access and request volumes to the account. Its report lists, under what did not go well, that "the incident was initially handled as an account-creation issue rather than a data-access event." That cost almost four months between the access and confirmation. The report does not say what prompted the October investigation; a Bugzilla commenter has asked.

What DigiCert says was and was not affected

According to the report, the account could not write records, act as a validation approver, or request, approve or issue certificates. The CA systems run on separate network segments, and a log review found no validation, issuance or revocation activity tied to the account. DigiCert lists zero affected certificates and did not stop issuance. CertCentral, DigiCert ONE, customer login credentials and issued certificates are described as unaffected.

What DigiCert has not published is the size of the exposure. The report gives no count of affected people, organizations or documents and says summary statistics are available to root program representatives on request. A commenter asked on November 5 whether this was subscriber verification data and how large the set was; DigiCert had not answered that question at the time of writing. DigiCert's notification email to customers says it is still reviewing identity documents and will contact the people whose documents were involved once that review is finished.

What to do

1. Work out who is exposed. List everyone at your organization who has dealt with DigiCert validation: certificate requesters, organization contacts, EV verified contacts and approvers, plus anyone who uploaded an ID or utility bill. Former employees count too, since this is archived data.
2. Warn those people directly. Expect emails and calls that use real names and real order context: urgent renewal notices, requests to "re-verify" your organization, approval links, or a caller asking for a domain control code or a callback number change. Tell them to start any DigiCert interaction from a bookmarked CertCentral login, never from a link or a number in a message.
3. Lock down validation on your side. In CertCentral, review the users list and the organization and domain contacts, remove anyone who has left, and make sure every account uses two-factor authentication. Revoke API keys that are unused or owned by departed staff, and check who is allowed to approve certificate requests for your account.
4. Watch for certificates you did not request. Set up Certificate Transparency monitoring for your domains, or at least search crt.sh for them now. A CAA DNS record limits which CAs may issue for your domains at all. Neither is a fix for this breach, but both catch the case where someone uses stolen context to talk a CA into issuing.
5. Handle the ID documents as personal data. If DigiCert notifies a person that their passport or license was in the set, follow your own breach handling: tell them, offer the identity protection your jurisdiction expects, and check whether a notification duty falls on you as well.
6. Do not reissue in a panic. DigiCert reports no certificate impact, and the archive held contact data and documents, with no mention of keys. TLS private keys are normally generated on your own systems when you create the certificate signing request. Rotate keys on your normal schedule unless you have a separate reason to suspect them.

The wider lesson

DigiCert's own conclusion fits most companies: a change to who can reach an internal tool is a security change, and authorization must not depend on network position. If you have internal admin apps that rely on "only reachable on the VPN" instead of their own access checks, a single migration can expose them the way this one did, and nobody will notice unless sign-ups and request volume are alerted on.

We look for this kind of exposure in attack surface management, finding internal tools that have become reachable from the internet, and our safeguarding and hardening work covers certificate issuance controls such as CAA and CT monitoring. To ask about either, open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: DigiCert incident report, Mozilla Bugzilla 2084460, BleepingComputer, Cryptika (Cyber Security News), WindowsForum, GBHackers.