DigiCert says a 2025 server migration left an internal business system reachable from the internet, and that unauthorized accounts read archived customer records, in some cases including passports and driver’s licences, between June 27 and July 2, 2026. The company states its certificate authority services and issued certificates were not compromised.
What happened
DigiCert, one of the world’s largest certificate authorities, has confirmed unauthorized access to an internal business system that stored archived customer information. The company is notifying affected customers, and its full incident report is on Mozilla’s public CA compliance tracker (Bug 2084460). Security outlets began covering it on November 4 and 5, 2026.
The exposed data was mostly business contact details: names, business email addresses, phone numbers and business addresses. In a small minority of customer accounts, the archive also held documents the customer had supplied, such as a passport, driver’s licence or utility bill.
DigiCert states that its certificate authority services, CertCentral, DigiCert ONE, customer login credentials and issued certificates were not affected. It has not published how many customers, people or documents are involved.
Sourcing note. We could not open the Bugzilla report directly. Details below come from outlets that cite it (GBHackers, Brandefense, BleepingComputer, SC Media) and agree with each other. Where they differ, we say so.
Timeline
The exposure window is far longer than the confirmed access window. The system was reachable from February 2025, but DigiCert has confirmed unauthorized reads only for June 27 to July 2, 2026.
| Date | Event | Basis |
| Feb 4, 2025 | Migration moves the system from a VPN-restricted segment to an externally reachable availability zone, exposing a self-registration endpoint | DigiCert report, as cited by GBHackers and Brandefense |
| Jun 18, 2026 | Internal team notices non-employee accounts, but concludes accounts without assigned applications cannot reach data | GBHackers |
| Jun 21, 2026 | A managed security research program reports the registration issue; a web application firewall already blocks new registrations on the external path | GBHackers, Brandefense |
| Jun 24, 2026 | DigiCert verifies that accounts can be created from outside | Brandefense |
| Jun 27 to Jul 2, 2026 | Unauthorized read-only access to archived customer data | GBHackers, SC Media |
| Jul 2, 2026 | Authorization fix rejects accounts with no application assignment (HTTP 401) | GBHackers |
| Oct 19, 2026 | DigiCert confirms a reportable data breach | GBHackers, SC Media |
| Oct 20, 2026 | Preliminary incident report filed | Brandefense |
| Nov 1, 2026 | Full incident report posted on the Mozilla CA tracker | Brandefense |
| Nov 4 to 5, 2026 | Customer notices circulate publicly and press coverage begins | BleepingComputer, GBHackers |
| Nov 6, 2026 | Final exposure audit and account-monitoring review scheduled; still ongoing | GBHackers |
Root cause: a network move without an authorization check
DigiCert’s report describes two failures that combined. The first was an infrastructure migration on February 4, 2025. It moved the archived-data system from a VPN-restricted network segment to an externally accessible availability zone.
The second was an authorization gap. The move exposed a self-registration endpoint inherited from an account management platform that DigiCert also uses elsewhere. Accounts created through it had no application assignment and were not subject to MFA. They still received default read-only permissions that reached archived customer records.
The system ran its own account manager instances, separate from DigiCert’s customer-facing products. Employees authenticated with MFA, but the registration path did not require it.
DigiCert named three contributing factors:
- Inadequate security review during the migration
- Insufficient monitoring of account activity
- An authorization model that did not anticipate self-registration
No CVE has been assigned or cited. This was a configuration and access-control failure, not a software vulnerability in a vendor product. The lesson is that where a system sits on the network cannot stand in for per-endpoint permission checks.
Attack methodology and attribution
What is confirmed. The access path was simple. Someone outside DigiCert registered accounts through the exposed endpoint and used them to read archived records in read-only mode. DigiCert’s logs show no certificate issuance, validation or revocation activity tied to these accounts. They could not modify records or approve validations.
What is not public. The report, as described in the coverage we reviewed, does not identify who created the accounts. It does not name a malware family, a threat group or a state sponsor. It does not report lateral movement or privilege escalation. We found no claim of responsibility and no report that the data was published or sold. Treat any attribution you see elsewhere as unverified.
Our assessment. The pattern fits opportunistic discovery of an exposed registration form, not a targeted intrusion into DigiCert’s CA infrastructure. That is an inference from the short access window and the read-only scope, not a finding from DigiCert. The six-day window followed DigiCert’s own detection of non-employee accounts on June 18, which suggests the endpoint was being probed or used while the company was still triaging it.
DigiCert’s first review wrongly concluded that accounts with no application assigned could not read data. BleepingComputer quotes the company as saying the incident was initially handled as an account-creation issue rather than a data-access event.
Impact assessment
The impact is a privacy and fraud-risk problem, not a trust-chain compromise. Nothing reported suggests anyone could issue or alter a certificate.
| Dimension | What is known |
| Data exposed | Names, business emails, phone numbers, business addresses; for a small minority of accounts, passports, driver’s licences or utility bills |
| Scale | Not disclosed. DigiCert says only a “small proportion” of archived data; no customer, person or document count |
| CA services and certificates | Not affected, per DigiCert: CA services, CertCentral, DigiCert ONE, login credentials and issued certificates |
| Customer action on certificates | DigiCert says none needed; active certificates remain valid |
| Operational disruption | None reported |
| Financial loss | Not disclosed |
| Regulatory | DigiCert calls it a reportable breach. We found no regulator statement or enforcement action as of November 6 |
Who carries the risk. People who supplied an identity document face the longest tail, because a passport or licence cannot be rotated like a password. Everyone named on file faces targeted phishing that uses DigiCert branding, a real name and a plausible renewal or validation request. That is an expected use of this kind of data, not a reported campaign.
Reputation. The gap between exposure and confirmation is the harder story. The system was reachable for about 17 months, per outlets counting from the February 2025 migration, and confirmation of data access took until October 19, 2026. For a company whose product is trust, that timeline will draw scrutiny from customers and auditors.
Why it matters for OT, PKI and industrial device identity
No OT impact has been reported. None of the sources we reviewed mention industrial control systems, SCADA or IoT devices. The incident did not touch certificate issuance, so deployed device certificates are not at risk from this event, per DigiCert. What follows is our analysis of why industrial teams should still care.
Industrial PKI depends on a small number of vendors. Plants, utilities and device makers rely on public and private CAs for TLS on engineering portals, code-signing for firmware and software, and identity for connected devices. A CA’s internal business systems sit close to that chain. The February 2025 migration shows how an ordinary infrastructure change can expose an administrative system the CA’s own security program did not intend to expose.
Identity-proofing documents are a liability. Validation for organization and code-signing certificates can require identity documents. If your OT vendors or integrators submitted passports or licences for engineers, those scans may sit in an archive you do not control. Ask what each vendor retains and for how long.
Exposed administrative systems are the common thread. The same failure pattern, a management or registration interface reachable from outside with weak authorization, drives many industrial incidents. A VPN-only interface that quietly moves to a public subnet during a migration is a risk in a historian, an engineering workstation gateway or a remote-access broker, just as it was here.
Related 2026 context. In April 2026, a separate DigiCert incident involved attackers who reached a support portal and obtained 60 EV code-signing certificates, 27 of which were tied to attacker activity. No source we reviewed links that incident to this one. It is a reminder that CA support and business systems, not only the CA core, are targets worth defending.
Incident response and recovery
DigiCert reports these steps as taken:
- Disabled the self-registration feature
- Moved remaining endpoints behind private-IP load balancers
- Reset passwords for business-system users
- Added alerts on file access and request volume
- Added a security sign-off requirement for network changes and ran a penetration test (reported by Brandefense)
The authorization fix went live on July 2, 2026. Earlier, a web application firewall had blocked new registrations on the external path, which stopped account creation but not access by accounts that already existed.
Still open. A final exposure audit and a review of account-creation monitoring were scheduled for November 6 and are described as ongoing. DigiCert is still reviewing identity documents to determine which individuals were affected and says it will notify them when that review ends. Customers began receiving general notices; cloud architect Fabian Bader shared one publicly.
Our read. The remediation addresses the exposure and the monitoring gap. The harder fix is process: DigiCert’s own account of the June 18 triage shows the incident was classified as an account-creation issue for months, which delayed confirmation until October 19.
Security recommendations
If you are a DigiCert customer
- Work out which people gave DigiCert a name, email, phone or address, and whether anyone uploaded a passport, licence or utility bill during validation.
- Leave certificates in service. DigiCert says no action is needed on active certificates, so do not revoke or reissue because of this notice.
- Warn the named contacts. Those who supplied identity documents should watch their accounts and credit records and consider a fraud alert where their country offers one.
- Brief your mail and help-desk teams to expect messages that use DigiCert branding and real names. A genuine notice will not ask for a password, code or document upload through a link.
- Open CertCentral by typing the address, not through a link. Review the user list and API keys, and remove people who have left.
- Confirm any unexpected validation call or email through your account, not through the message that asked.
If you run internal systems, including OT-adjacent ones
- Scan for exposure after every migration. Run an external scan and an unauthenticated test against any system that changes network segment. Do not rely on the change ticket.
- Enforce authorization at the endpoint. Network position is not access control. Test that an account with no role or assignment can read nothing.
- Remove or disable self-registration wherever it is inherited from a shared platform and not needed.
- Require MFA for every account type, including accounts created by registration flows.
- Alert on new non-employee accounts and on bulk reads of archived files, and triage them as possible data access, not just account creation.
- Minimize and age out identity documents. Keep proofing scans only as long as the rules require, and store them away from general business systems.
- Review CA and PKI vendors as third parties. Ask what personal data they hold about your engineers and how they scan their own migrations.
- Treat PKI administration as tier-0. Keep CA, registration-authority and certificate-management consoles off general networks, and inventory the certificates your plant and devices depend on.
Latest developments and open questions
As of November 6, 2026, DigiCert is still reviewing identity documents to identify affected individuals, and its final exposure audit is ongoing. We found no new technical findings beyond the incident report and no regulator statement.
Questions DigiCert has not answered publicly:
- How many customers, people and documents were affected?
- How many unauthorized accounts were created, and from where?
- Does DigiCert have evidence of copying or onward distribution, or only of reads?
- Have regulators been notified, and in which jurisdictions?
- Why were identity documents retained in an archive, and for how long?
Other DigiCert incidents in 2026 (separate events)
| Month | Incident | Relation to this breach |
| April 2026 | Attacker reached a support portal through a malicious file sent via customer chat; 60 EV code-signing certificates revoked, 27 tied to attacker activity and some used to sign Zhong Stealer malware (Mozilla Bug 2033170, Help Net Security) | No source links it to this breach |
| July 2026 | Compliance incident over undisclosed CRL distribution points in the public CA database, reported as a disclosure gap and not as certificate mis-issuance (Mozilla Bug 2055047) | Unrelated |