DigiCert Data Breach: Self-Registered Accounts Read ID Files

Certificate authority DigiCert has disclosed a data breach in an internal business system that held archived customer records. According to the company’s incident report, as summarized by BleepingComputer and The Record, a server migration in February 2025 left the system reachable from the internet, outsiders created accounts through a self-registration feature, and an authorization flaw let those accounts read archived customer data, including some identity documents. DigiCert says certificate issuance, CertCentral and DigiCert ONE were not affected.

Both outlets published on November 5 and 6, 2026 and cite DigiCert’s incident report filed on Mozilla’s Bugzilla, the public tracker where certificate authorities report incidents to browser root programs. We could not retrieve that report directly for this article, so everything below is attributed to DigiCert as reported by those outlets.

What happened

BleepingComputer reports that “a February 2025 server migration mistakenly exposed an internal business system to the internet.” Before that, the system was reachable only through a VPN. The system had a self-registration feature, so people outside DigiCert could create accounts on it, and an authorization flaw gave those accounts read-only access to archived customer information.

The Record quotes DigiCert’s post-mortem as saying the system was “externally accessible when that was not intended,” that the migration “was treated as an infrastructure change rather than a security change,” and that there was “insufficient alerting for new account creation through the externally-accessible endpoint.”

Timeline

Outlets give slightly different days for the June discovery (June 18 and June 21), so we give the month only.

Confirmed vs not confirmed

What DigiCert changed

BleepingComputer lists the remediation as: restricting access to the affected system, disabling self-registration, adding further access controls, and earlier fixes to restrict access and address the authorization flaw. DigiCert says it is notifying individuals whose identity documents were involved once its review is complete.

What engineers should check in their own environment

Nothing here required a novel exploit. Three ordinary weaknesses lined up, and each one is common in internal tooling.

1. Network moves that remove the only control. The system was safe only because it sat behind a VPN. When the migration changed that, nothing else in front of the app had been designed for internet exposure, and, per DigiCert’s own wording, nobody treated the move as a security change. Look for internal apps whose access model is “only reachable on the corporate network”: admin consoles, archive viewers, back-office CRMs, support tools. For each, ask what stops a stranger if the network boundary disappears tomorrow. Our piece on why identity has become the new perimeter in the cloud covers the general shift.

Practical checks:

• Add “does this change internet reachability?” to infrastructure change reviews, and route a yes to security review.
• Continuously diff your external attack surface (DNS, load balancer listeners, security groups, public IPs) against an allow-list of systems meant to be public.

2. Self-registration on internal systems. A sign-up form is reasonable on a customer portal and dangerous on an employee tool. If an app supports self-registration, find out whether it is enabled, which identity providers it trusts, and whether new accounts get any permission by default. Better still, disable local sign-up and require SSO from your identity provider, so creating an account means passing your MFA and joiner process.

3. Authorization that depends on assumptions. DigiCert first judged the unknown accounts harmless because they were not assigned to an application, yet a permission-check gap still exposed archived data. Two lessons follow: unassigned is not the same as unprivileged, and archive or reporting features are often checked less strictly than the main workflow. Test authorization with a freshly created, unassigned account against every read path, including exports and archives.

And watch account creation. DigiCert’s report cites insufficient alerting on new accounts through the external endpoint. An alert on accounts created outside your provisioning flow is cheap and would have shortened the gap between discovery and confirmation. Pair it with a regular review of unused and unexpected accounts and identities.

What it means for DigiCert customers

Based on DigiCert’s statements, there is no certificate action to take: no forced reissuance and no credential reset. If your organization went through DigiCert organization or extended validation and supplied identity documents, watch for a notification, and treat unexpected messages that reference your DigiCert account or validation details with extra care, since names, emails, phone numbers and addresses are exactly what targeted phishing uses.

Sources and verification

Hacking NewsData BreachDigicertCertificate AuthorityAccess ControlAuthorization