DigiCert has told browser root programs that an internal system archiving customer-supplied information was reachable from the internet from February 2025 until July 2026, and that an account nobody had assigned to the system read part of its archive between 27 June and 2 July 2026.
The disclosure sits in DigiCert’s full incident report, posted to Mozilla’s Bugzilla on 1 November after a preliminary report on 20 October. DigiCert describes the system as a business archive for information customers give it to validate their identity. The report states that “No certificates were issued, modified, or revoked as a result of this incident.” DigiCert says its certificate authority services, CertCentral and DigiCert ONE were unaffected, and that customer login credentials remain secure.
What DigiCert says happened
The report starts on 4 February 2025, when the archive system moved from a VPN-restricted network segment to a different availability zone. In DigiCert’s words, “This migration inadvertently allowed this internal business system to be accessible externally.”
The system runs its own instance of the account manager that DigiCert also uses for customer-facing products. That software includes a self-service registration feature built for other deployments. On the archive system the feature became reachable, and accounts created through it skipped the multi-factor authentication DigiCert otherwise requires. They defaulted to read-only mode, but DigiCert says these unassigned accounts could still read archived data.
Discovery came in steps. On 18 June 2026 an internal team noticed accounts that did not belong to DigiCert, concluded they had no data access and put the system behind a web application firewall that blocked new account creation from outside. On 21 June a report from DigiCert’s managed security research program pointed to account creation through external access, and DigiCert verified it on 24 June. A software patch with an authorization restriction reached production on 2 July. DigiCert says it did not know at that point that a small share of archived data had been read.
That changed on 12 October, when DigiCert first suspected unauthorized access to the archive. On 19 October it confirmed access to a subset of the data and judged the event reportable under browser root program rules. Its investigation puts the data access window at 27 June through 2 July.
What was exposed
DigiCert says most of the data was business contact information: names, business email addresses, phone numbers and business addresses. A small minority of customer accounts also held a customer-provided document with a name and address, such as a driver’s license, passport or utility bill. The report says the access could not write records, act as a validation approver or issue certificates, and that a log review found no validation, issuance or revocation activity tied to the account.
DigiCert says it has contacted affected customers and reported the incident to law enforcement. The report gives no count of affected customers. Commenters on the Bugzilla thread asked for numbers and for the archive’s role in subscriber validation on 5, 6 and 7 November; DigiCert’s reply on 7 November restated the data categories and did not add a figure.
The causes DigiCert lists
The report’s first contributing factor is that the system’s network accessibility changed without a security review of the resulting attack surface. The second is the unused registration feature that came along with the shared software. DigiCert’s corrective steps include a 28 August policy requiring security sign-off for network access control changes on internal tools, a 24 October deactivation of the self-registration feature on every business system instance, and a move of the remaining externally reachable endpoints onto private-IP load balancers. On 29 October it assigned ownership for confirming firewall, monitoring and access review coverage whenever a system’s accessibility changes. DigiCert marked its last action items complete on 6 November.
What it means for the security leader
In our reading, the report shows a pattern that most organizations share. Archives of customer-supplied identity documents tend to live on internal tools that nobody counts as external attack surface, so they sit outside the review that a customer-facing system receives. A network move is a change of exposure, and DigiCert’s own first contributing factor is that the 2025 move happened without a review of what became reachable. The shared software added a second gap by shipping a feature the archive never needed.
The timeline also bears on detection. The unassigned accounts were visible on 18 June, nine days before the data access window opened, and the internal reading at the time was that they had no data access. The firewall rule that day blocked new account creation from outside. The report records that DigiCert verified the remaining non-DigiCert accounts, which had been used for a penetration test, as removed on 15 October, and completed password resets for all users of the system on 17 October.
Our earlier coverage of certificate management failures and their cost looked at the certificate side of trust infrastructure. This disclosure concerns the customer paperwork behind it.
What defenders should do
Inventory every internal system that stores customer or employee identity documents, including archives and ticket attachments, and confirm which network paths reach each one. Add a security review step to infrastructure migrations that tells the change owner what the new location exposes. Search internal tools for self-registration, invitation and password-reset features that the deployment does not use, and turn them off. Alert on account creation and permission changes in tools that hold personal data, which is the control DigiCert listed as its action item 13. If you are a DigiCert customer, watch for the direct notice DigiCert says it sent, and treat unexpected mail that cites your validation details with extra suspicion.
Management interfaces and admin consoles follow the same logic, as our opinion piece on keeping every management interface on a network only administrators reach argues.
