A February 2025 server migration made a previously VPN-protected DigiCert business system reachable from the internet. A self-registration feature and an authorization flaw then allowed an outside account to read archived customer records between June 27 and July 2, 2026. DigiCert said the breach did not compromise its certificate-issuance services.
1
11
24
How the exposure happened
The migration moved an internal system to a different network segment and inadvertently removed the VPN barrier that had restricted access. The application allowed users to create accounts through self-registration—a feature not intended to give outsiders access to the archive.
3
5
11
The flaw was in authorization: accounts without an application assignment could still read archived records. Reporting says self-registered accounts did not require multi-factor authentication (MFA), unlike staff accounts.
11
25 MFA’s absence was part of the access-control gap; the reporting describes an authorization failure, not an MFA bypass that gave an attacker access to certificate issuance.
11
24
What happened, and when
- February 2025: The migration made the internal system externally reachable. A timeline in reporting dates the change to February 4.
3
5
- June 18, 2026: Staff noticed accounts that did not belong to DigiCert. An initial assessment wrongly concluded that accounts without an application assignment could not access data. Reporting also says a web application firewall blocked new account creation through the external route.
5
26
- June 21: DigiCert’s incident report says the company determined the system was externally accessible and an unassigned account had been created.
24 Reporting also describes a researcher alert around this time.
18
22
- June 27–July 2: DigiCert later determined that an unauthorized account accessed a subset of archived data during this period.
1
24
- July 2: DigiCert deployed an authorization fix that addressed account creation and denied archived-data access to unassigned accounts.
24
- October 19: DigiCert confirmed unauthorized access to archived data and classified it as a reportable event.
24
The timeline distinguishes two issues: blocking new registrations and preventing existing unassigned accounts from reading the archive. The July 2 authorization change addressed the access problem, but DigiCert did not confirm that customer data had been read until October 19—more than three months after the reported access window ended.
18
24
What customer information was exposed
Most of the accessed records contained business contact details: names, business email addresses, phone numbers and business addresses. A small minority also included identity documents, such as passports, driver’s licenses or utility bills. Some representatives had provided those documents for identity validation.
1
12
24
The available reporting does not state the total number of affected customers. DigiCert had begun notifying affected customers, but the sources do not establish how many notices were ultimately sent or the status of a review of exposed identity documents.
6
7
What DigiCert said was not affected
DigiCert said its certificate-authority services, CertCentral, DigiCert ONE, customer credentials and issued certificates were not compromised.
9 The incident involved archived customer records in an internal business system; it was not a reported compromise of certificate issuance.
1
24
The available reporting does not establish the full status of every validation capability or the specific audit and alert-review work described in some accounts. Those details should not be inferred from the confirmation that certificate issuance and named services were unaffected.
Why the incident went unconfirmed for months
The first assessment focused on the presence of unauthorized accounts and assumed that accounts without an application assignment could not reach customer data. That assumption was incorrect: the authorization model still allowed those accounts to read the archive.
5
24
The sources establish that DigiCert noticed the access issue in June, applied a fix in July, and confirmed data access in October. They do not provide enough detail to reconstruct every step of the investigation or explain fully why confirmation took until October. The number of affected customers and the complete status of customer notifications and document review also remain unspecified in the available reporting.
6
24