The DigiCert data breach exposed archived customer records after an unauthorised account read them between 27 June and 2 July 2026. DigiCert, a certificate authority, confirmed the access on 19 October 2026. The records held names, business email addresses, telephone numbers and business addresses, with identity documents for a small minority of accounts. DigiCert disclosed no number of affected customers and called the affected portion of its archive small. The confirmation appeared in DigiCert's own incident report, published in Mozilla's public Bugzilla compliance tracker as bug 2084460. The preliminary report was filed on 20 October, the full report was posted on 1 November, and public reporting followed on 5 November 2026.
Exposure of the archive
On 4 February 2025 DigiCert moved an internal business system from a network segment restricted to VPN traffic into a different availability zone. The move left the system reachable from the internet, although it was never meant to be externally accessible. The system archives identity-validation information that customer representatives provide to DigiCert.
That business system runs its own instances of an account manager platform also used for customer-facing products. The platform includes an optional self-service registration flow, and after the migration the flow became available on the business system by mistake. Staff sign in with multi-factor authentication, but accounts created through self-registration received none of that protection: no application assignment, no multi-factor authentication, and read-only access by default. Those unassigned accounts could then read archived customer data because of an authorisation flaw.
DigiCert's report states the lesson in a single sentence: "Authorization for a business system must not be delegated to its network position." The migration changed the network position of the system without a security review, and monitoring for new account creation was not reassessed after the move. The authorisation model treated the absence of an application assignment as proof of no access. That assumption was wrong, and an exposed registration endpoint became a data breach.
Timeline of discovery and confirmation
External accounts on the business system came to DigiCert's attention on 18 June 2026, when its internal team noticed accounts that did not belong to DigiCert staff. The reviewer concluded that the accounts could not reach data because they were not assigned to an application. That conclusion was incorrect. The same day, DigiCert placed the system behind a web application firewall, blocking new account creation from outside.
On 21 June 2026 a report through DigiCert's managed security research program warned that accounts could be created on the system through external access, and DigiCert verified that ability on 24 June. The unauthorised reading of archived records then took place between 27 June and 2 July, according to the later investigation. A software patch with an authorisation restriction was released to production on 2 July, the same day the access window ended, requiring account-manager token validation and returning HTTP 401 responses to accounts with no assigned application. From 9 July, only VPN traffic could reach the business system hostnames through the web application firewall, apart from approved external endpoints.
At the time, DigiCert had no knowledge that archived data had been read. The report states the point directly: "The incident was initially handled as an account-creation issue rather than a data-access event." Suspicion of possible unauthorised access first arose on 12 October 2026. On 15 October, DigiCert added alerts at application level for file access and request volumes, and deleted the remaining accounts that did not belong to its staff. Password resets for all business system users were completed on 17 October.
Confirmation followed on 19 October 2026, when DigiCert confirmed unauthorised access to a subset of archived data and determined the event was reportable under browser root program requirements. DigiCert filed its preliminary incident report on 20 October, followed by the full report on 1 November. In early November 2026, DigiCert started sending notices to customers. Fabian Bader, a cloud architect, posted his notification on X, while Troy Hunt, creator of Have I Been Pwned, posted the notification there too and asked if others had received one.
Customer records in the affected archive
Most of the accessed records held business contact information: names, business email addresses, telephone numbers and business addresses. A small minority of customer accounts included additional personal data in the form of a customer-provided document, such as a driving licence, passport, utility bill or other document carrying a name and address. Those documents had been submitted during identity validation before some certificates were issued.
According to DigiCert, review of the identity documents continues, with notification of everyone affected to follow once it finishes. The notification quoted by BleepingComputer states that the information involved was limited to names, business email addresses, phone numbers and business address shared with DigiCert and, if provided, may have included an identification document.
No source has disclosed a customer count. DigiCert calls the affected portion of its archive small, and gives no further measure of it. Its appendix says summary statistics can be supplied to root program representatives on request. When BleepingComputer published on 5 November 2026, it had asked DigiCert for the number affected and had no answer. Until DigiCert publishes a figure, none can be attached to this breach.
The people affected are customer representatives whose details sit in DigiCert's archived business records, including anyone who bought a certificate from DigiCert or through a reseller and provided business contact details or identity documents during validation.
Even with no password exposed, a business email address in a breach file gives attackers material to work with. The address can be used for targeted phishing messages quoting the real name, telephone number and business address, and referencing a real DigiCert certificate order. That pattern is described in the guide on how phishing uses a leaked email: the leaked address makes the message possible, and a fake sign-in page or fake payment request does the rest. Identity documents raise the stakes for the small minority whose documents were in the archive: a document combines a name and address with identification harder to replace than a contact detail.
Certificate services and issued certificates
DigiCert states that its certificate authority services, CertCentral and DigiCert ONE were unaffected and remain secure. Customer login credentials stay secure, DigiCert says, as do DigiCert-issued certificates, which remain valid and fully trusted, with no action needed on active certificates. Zero certificates were affected, the incident report records, with none issued, modified or revoked because of the incident.
Reading records was all the unauthorised account could do. Writing records, approving validations and issuing certificates were all beyond it. Logs of certificate authority and validation activity, reviewed by DigiCert, showed no validation actions, certificate issuance or revocation activity linked to the account.
Remediation and system changes
DigiCert updated its policy on 28 August 2026, so that network access changes for internal tools require security sign-off. An external penetration test was completed on 31 August.
File-access and request-volume alerts were added on 15 October, and password resets for all business system users were completed on 17 October. Self-registration was disabled on all instances on 24 October, and the remaining endpoints were moved behind private-IP load balancers on the same day. The company assigned a single named owner for the system's security on 29 October and completed a least-privilege review of the permissions model on 30 October.
Company instructions to affected customers
DigiCert's notification tells affected customers that the company is still reviewing identity documents and will notify them once that review is complete. A notice received should be kept, since it records what DigiCert says was exposed for that account. From public information, customers who bought certificates from DigiCert or a reseller and have not received a notice cannot yet tell whether their records were in the affected portion.
Published breach guidance recommends treating unexpected messages that mention DigiCert, a domain name or a certificate order as suspect, even when the message quotes a real name and telephone number. Ignoring links in such messages and reaching DigiCert through its own website, or through the account contact already known to the customer, is safer. The AliasFleet guide on how to check if your email was leaked describes a check of whether an address appears in known breach listings, not whether a specific DigiCert record was included.
Customers who submitted a passport or driving licence during validation are advised to ask DigiCert in writing whether their document was among those reviewed, and what support the company offers. Recovery details shared with the business email address make those accounts worth reviewing: the guide on whether someone can read emails with only an email address sets out why an address alone does not open a mailbox, while a password entered on a fake sign-in page does. Whether an address is safe to hand over is decided by the pre-signup check covered in the guide on how to check what a site does with your email first.
Published breach guidance also covers passwords and account access. A password reused anywhere the business email address was used is changed, and multi-factor authentication is enabled on the mailbox and on the DigiCert account where available. A changed password limits reuse after a leak, while multi-factor authentication keeps a stolen password from opening the account alone.
Your business address may be in this file. Check whether it is, do the password work above, and then fix the part you control: the address you hand out next time. One AliasFleet alias per service means the next leak can only point back to the service that leaked it. Founders Club is $7 a month, locked forever, instead of $12. Early members only.
Outstanding items from the incident report
DigiCert's incident report lists two action items due 6 November 2026, which is today. First, an internal audit to confirm that no business-system origin server is externally accessible. Second, a final review of automated alerting for unexpected account creation and changes to account or user permissions, routed to security operations with a defined escalation path. As last read, the report listed both as ongoing, with no published result for either item at the time of writing.
Customer count is the second open question. No number of affected people, organisations or documents has been published, and the identity-document review is still in progress. The scale cannot be stated beyond the company's own description of a small portion of its archive until a count is published or the review completes.
Notification is the third open question. Beyond the emailed notices that began in early November, the sources read give no account of how DigiCert notifies individual customers, or whether customers who bought through resellers are notified directly or through the reseller.
Top comments (0)