DigiCert, one of the world's largest certificate authorities, published its full incident report on 1 November 2026 and began notifying affected customers.
The central fact is not a hack in the usual sense. In February 2025, a migration moved an internal business system out of a VPN-restricted network, making it reachable from the internet. That system shared an account management platform with DigiCert's customer-facing products, and it inherited a self-registration feature that was never meant to be available there.
So anyone could create an account without multi-factor authentication. A separate permissions flaw meant those accounts received default read-only permissions that reached archived customer records.
Nobody had to break anything. The front door had a sign-up form on it.
The timeline is the story
Date | What |
|---|---|
February 2025 | Migration exposes the internal system to the internet |
18 June 2026 | DigiCert finds unauthorized accounts, dismisses them as harmless because they were not assigned to an application |
27 June to 2 July 2026 | An unauthorized account reads archived customer data |
2 July 2026 | Account creation shut down, after a researcher raised the alarm |
12 October 2026 | DigiCert begins investigating whether customer data was actually accessed |
19 October 2026 | Confirms the access, classifies it as a reportable event |
1 November 2026 | Full incident report published |
Two gaps in that table matter more than the breach itself.
Sixteen months of exposure, from the migration to the shutdown.
Four months between finding the accounts and investigating the data. DigiCert's own report is candid about why: "The incident was initially handled as an account-creation issue rather than a data-access event." Unauthorized accounts existed, were noticed, and were filed as a hygiene problem rather than a question about what they had read.
The company also identified the detection failure plainly, saying the system had "insufficient alerting for new account creation through the externally-accessible endpoint" or for request volume from its internal endpoints.
What was taken, and what was not
Accessed, read-only, between 27 June and 2 July:
Names, business email addresses, phone numbers, business addresses
For a small minority of accounts, customer-provided identity documents: passports, driver's licences, utility bills
Those documents are the serious part. They were submitted for certificate validation, which is a legitimate requirement, and they are precisely the material used for identity fraud. Unlike a password, a passport number cannot be rotated.
Not affected, according to DigiCert:
Certificate authority services, CertCentral and DigiCert ONE
Customer login credentials
Issued certificates
The unauthorized account had read-only access. It could not modify records, approve certificate validations, issue certificates or revoke them, and DigiCert's log review found no issuance, validation or revocation activity tied to it.
Customers do not need to replace certificates. Active certificates remain valid and no action is required on them unless DigiCert contacts an account directly.
What has not been disclosed: how many customers or individuals are affected. DigiCert describes it as a "small proportion" of its archive and has published no count.
Why the reassuring part is the important part
It would be easy to read "CA services unaffected" as corporate deflection. It is not. It is the single most consequential fact here, and it deserves more attention than the breach.
A certificate authority sits at the root of web trust. An attacker who can issue certificates can impersonate any website, intercept traffic and sign malware as a trusted publisher. The consequences would not be limited to DigiCert's customers. They would reach anyone whose browser trusts DigiCert, which is effectively everyone.
That did not happen, and the reason is architectural. DigiCert states its certificate authority systems operate on separate, secured network segments. The archive that was exposed and the machinery that issues certificates were not on the same network. A migration error in one did not reach the other.
This is segmentation doing exactly what it is for, in the case where it mattered most. Worth saying clearly, because segmentation is usually invisible and only gets discussed when it fails.
Why it matters
The exposure was created by a routine change. No vulnerability was exploited and no credential was stolen. Someone moved a system during a migration and the network boundary it depended on went away with it. That is an ordinary operational event, and it is how a very large share of internet-facing exposure gets created.
Shared platforms carry their features with them. The self-registration endpoint existed because the internal system used the same account management platform as the customer-facing products. On a customer-facing product, self-registration is a feature. On an internal archive, it is a public door. Nobody chose to put it there.
Finding unauthorized accounts is a data question, not an account question. This is the transferable lesson. DigiCert noticed the accounts in June and asked the wrong question about them. The right question, asked four months later, had a different answer.
Identity documents outlive the incident. Names and business emails are routine exposure. A passport scan is not. Validation documents are collected because certificate issuance requires identity proof, and they sit in archives long after the certificate is issued.
Trust infrastructure gets held to a higher standard, fairly. DigiCert's previous incidents, a support-system breach involving code-signing certificates and a 2024 DNS validation error that forced certificate replacements, are separate from this one. But a company whose product is trust accumulates scrutiny.
What to do if you are a DigiCert customer
Find out what your organisation submitted. Ask whoever manages your DigiCert account which representatives provided a name, business email, phone number or address, and whether any identity documents were uploaded for validation.
Treat identity documents as the priority. If a passport, driver's licence or utility bill was submitted, that is a different risk class from contact details and may warrant monitoring the individual concerned, not just the company.
Do not replace certificates. DigiCert says no action is needed and that issuance, validation and revocation were unaffected.
Expect targeted phishing. Business contact details plus knowledge that you are a DigiCert customer is enough to construct a convincing certificate-expiry or validation message. Verify any such request through the DigiCert portal directly.
Check your own notification. DigiCert is notifying affected customers individually, so the absence of a notice is meaningful information.
And a question for your own estate, because this is the part that generalises: when a system moves during a migration, does anyone verify that the network restrictions it relied on moved with it? That single check is what separates DigiCert's situation from a normal Tuesday.
