DigiCert, one of the world's largest certificate authorities, is notifying customers that an unauthorized account read archived customer records, including in some cases passports and driver's licenses, after a 2025 server migration quietly left an internal business system reachable from the public internet for more than 16 months.
The company's full incident report, filed with Mozilla's root program in Bugzilla bug 2084460, traces the exposure to February 4, 2025, when the internal system was moved from a VPN-restricted network segment to a different availability zone. The move inadvertently made the system externally accessible, and because the system ran its own instance of the same account manager platform DigiCert uses for customer-facing products, a self-registration feature intended for other use cases came with it.
That combination proved decisive. Self-registered accounts were not subject to the multifactor authentication DigiCert otherwise requires, because they were not assigned to an application that required it. They were placed in read-only mode by default, but a separate authorization flaw meant those unassigned accounts could still browse archived data. DigiCert says the access was read-only: the account could not write records, act as a validation approver, or issue certificates.
Most of the data involved was business contact information for customer representatives: names, business email addresses, phone numbers, and business addresses. A small minority of accounts also held a document a customer had provided to validate identity, such as a driver's license, passport, or utility bill. DigiCert has described the material accessed as a small proportion of its archive, but it has not published how many customers or individuals were affected. It says it is still reviewing the identification documents to identify the individuals involved, has contacted affected customers, and has reported the incident to law enforcement.
The timeline is the uncomfortable part. DigiCert staff first observed non-DigiCert accounts on the system on June 18, 2026, but a reviewer concluded they had no data access because they were not assigned to any application, and the incident was initially handled as an account-creation issue rather than a data-access event. A report from DigiCert's managed security research program followed on June 21, and an authorization patch released on July 2 ended the exposure. Later forensic work placed the actual data-access window between June 27 and July 2, 2026. DigiCert says it first suspected archived data had been accessed on October 12, and confirmed a reportable event on October 19.
DigiCert is explicit that its core trust operations were not touched. Its certificate authority services, CertCentral, and DigiCert ONE were unaffected, no certificates were issued, modified, or revoked because of the incident, customer login credentials remain secure, and a review of logs found no validation, issuance, or revocation activity tied to the unauthorized account.
Since then, the company says it has blocked registration at its firewall, restricted the system's hostnames to VPN traffic, completed password resets, deactivated self-registration, moved remaining endpoints onto private-IP load balancers, added alerts on file access and request volumes, and assigned a single owner for the system's security posture. Its root-cause analysis cites three failures: a network change made without a security review, monitoring that was never reassessed after the migration, and an authorization model that never contemplated self-registration.
For enterprise security teams, the lesson is familiar: an internal system's safety cannot rest on its network position alone. A routine migration changed this system's exposure, its identity defaults assumed only staff would ever arrive, and the first human review dismissed the warning sign. DigiCert says no action is needed regarding active certificates, but representatives whose identity documents were read will be watching for its final count.