The DigiCert data breach: ID documents read from a validation archive

The DigiCert data breach exposed archived records that customer representatives gave the certificate authority to prove who they are, and a small minority included documents such as passports or driving licences. DigiCert's full incident report, filed on 1 November 2026, says an outside account read part of the archive between 27 June and 2 July 2026. No certificates were affected.

• DigiCert says an internal business system that archives customer-provided validation information became reachable from the internet after a migration on 4 February 2025.
• A self-registered account without multi-factor authentication read part of the archive between 27 June and 2 July 2026. DigiCert confirmed the access on 19 October 2026.
• Most exposed data was business contact information. A small minority of accounts also held a document such as a driving licence, passport or utility bill.
• DigiCert has not published how many people or documents were affected. It says no certificate was issued, changed or revoked.
• The incident sits beside two other October reports to Mozilla about registration authority records, from TWCA and D-Trust.

What happened in the DigiCert data breach?

The DigiCert data breach is a read-only exposure of an internal archive, not a compromise of certificate issuance. DigiCert says an internal business system holding information that customer representatives supply "to validate their identity" was reachable from outside its network. An account created through an unintended sign-up feature then read what DigiCert calls "a small proportion of archived data."

DigiCert disclosed the incident on 20 October 2026 in a preliminary incident report on Mozilla's public Bugzilla tracker. The full incident report followed on 1 November 2026, citing the Mozilla, Chrome, Microsoft and Apple root programme policies. It describes a February 2025 infrastructure migration that moved the system out of a VPN-restricted network segment.

That migration also exposed an account registration feature meant for other products. Accounts created this way were not subject to the multi-factor authentication that DigiCert staff use, and were read-only by default. However, "these unassigned accounts had access to archived data on the business system," the report says.

DigiCert says most of the accessed data was names, business email addresses, phone numbers and business addresses. "A small minority of customer accounts" also contained a customer-provided document "such as a driver's license, passport, utility bill, or other document with name and address." The account could not write records, approve validations or issue certificates, and DigiCert's log review found no validation, issuance or revocation activity linked to it.

Why did it take four months to confirm the access?

The first warning signs of the DigiCert data breach appeared in June 2026, but data access was confirmed only on 19 October. DigiCert's report explains why: an early review concluded, wrongly, that accounts without an assigned application could not reach data. The company says it handled the event "as an account-creation issue rather than a data-access event."

DigiCert knew outside accounts could be created before any data was read. On 18 June, staff noticed non-DigiCert accounts and put the system behind a web application firewall that blocked new sign-ups. On 21 June, DigiCert's managed security research programme reported that outside account creation was possible, and DigiCert verified it on 24 June. The access window opened three days later, on 27 June, while the fix was still being built. It shipped on 2 July, the last day of the window.

Retained logs and audit tables let DigiCert rebuild the access list and window. The report's main lesson is short: "Authorization for a business system must not be delegated to its network position."

Why do certificate authorities hold identity documents at all?

Certificate authorities hold identity documents because their own rules make them collect and keep validation evidence. On the photo ID route for individual code signing applicants, the CA/Browser Forum rules say the CA "MUST obtain a legible copy" of a government-issued photo ID, and validation records must be kept for at least two years after last reliance or certificate expiry.

The Code Signing Baseline Requirements, section 3.2.3.1, require a copy that "discernibly shows the Certificate Requester's face." The rule allows one alternative: a request signed with an existing qualifying personal certificate. DigiCert's report does not say which certificate products the exposed documents supported, so this is context for why such files exist, not a finding about this archive.

Retention is the second driver. The TLS Baseline Requirements, section 5.5.2, require the CA to keep documentation on the verification of certificate requests for at least two years after it was last relied upon or after the related certificates expire, whichever is later. The same section says the CA "MAY choose a greater value" for investigations. The rules set a floor, not a ceiling.

The DigiCert data breach is not the only recent incident involving such archives. D-Trust told Mozilla on 24 October that a delegated registration authority at E.ON had lost subscriber identity validation records for S/MIME certificates issued from 2015 to 2022, under a practice statement requiring seven years of retention after expiry. TWCA reported unauthorised access to a registration authority server on 29 October. DigiCert's own report lists both as related incidents that "dealt with privacy and management of archive data."

What does the DigiCert data breach mean for KYC and AML obligations?

The DigiCert data breach matters to compliance teams because regulated firms keep the same kind of archive for the same reason. Record-keeping rules in AML regimes require identification evidence to be kept for years, and each rule differs on whether a copy of the document is needed and when it must go.

In the UK, regulation 40 of the Money Laundering Regulations 2017 requires "a copy of any documents and information" obtained for customer due diligence, kept for five years from the end of the business relationship. Regulation 40(5) then requires the firm to delete that personal data, subject to narrow exceptions. A UK firm that keeps passport images past that point is in breach of regulation 40(5) unless an exception applies.

In the US, the bank Customer Identification Program rule at 31 CFR 1020.220 requires a description of the document relied on: its type, identification number, place of issuance and dates. It does not require an image. The description must be kept for five years after the record is made, and identifying information for five years after the account closes. Our CIP glossary entry covers the rule in more detail.

Under the GDPR, Article 5(1)(e) requires personal data to be kept "for no longer than is necessary" for its purpose, so an archive kept past its legal retention period is hard to defend. Holding images where a description would do also strains the data minimisation rule in Article 5(1)(c).

The DigiCert data breach is a prompt to recheck three existing duties. For customer due diligence, firms should know where document copies sit and whether a description would meet the rule. For record keeping, the deletion trigger needs to run, not just the retention clock. For third-party risk, any supplier that holds validation evidence for your staff, a certificate authority included, belongs in the vendor inventory.

What is still unknown about the DigiCert data breach?

The biggest gaps are scale, actor and notification. DigiCert has not published how many people or documents were exposed, who created the account, or what was done with the data. Its report calls the event unauthorised access but does not attribute it, and says summary statistics are available to root programme representatives on request.

Notification to individuals is not described in the public report. Neither is any filing with a data protection authority. Readers should not assume either has or has not happened; the Bugzilla report covers DigiCert's duties to browser root programmes, not its privacy law obligations.

Remediation of the DigiCert data breach is mostly done, though the bug remains open. DigiCert lists 11 of 13 action items as complete, including an external penetration test on 31 August, deactivation of self-registration on 24 October and a per-endpoint authorisation review on 30 October. Two items, an audit that no origin server is externally reachable and a final review of alerting for unexpected account creation, are due on 6 November 2026.

The wider risk from the DigiCert data breach is reuse. A leaked passport or driving licence image can be presented again to any service that accepts photographed documents. The Times Car breach confirmed the same exposure in car sharing, and the IDScan incident raised it for in-person ID checks. A check that inspects only the photographed document cannot tell a stolen image of a genuine passport from one presented by its holder.

There is also a design gap. Neither CA/Browser Forum rule set caps retention, while AML rules such as the UK regulations already add a deletion duty once the retention period ends.

How should compliance teams respond?

Start with the people, then the archive. Find out whether your staff submitted identity documents to DigiCert for certificate validation, and watch for any notice. Then audit your own document stores against the rules above, because the failure DigiCert describes can occur in any archive.

Four practical steps follow from DigiCert's report. Treat any change to an internal system's network exposure as a security change that needs review, as DigiCert now does. Check that every endpoint enforces authorisation itself instead of relying on a VPN or firewall. Alert on new accounts and unusual read volumes: DigiCert says its new request-volume alert would have fired on 1 July, more than three months before it confirmed the access. Map retention against the legal minimum and the deletion duty, and delete what has expired.

For onboarding, reduce the number of document images you hold. Where your regime accepts a description of the document, store that instead of a photograph.

Zyphe reads the NFC chip of an ICAO 9303 document, encrypts the result into the user's own vault split across thousands of nodes, and gives the business verification results and proofs rather than document copies. There is no central store of customer PII to expose. To see how this fits your record-keeping duties, book a demo.

The bottom line

The DigiCert data breach did not touch a single certificate, yet an outside account still read a validation archive that, for a small minority of accounts, held identity documents. The cause was ordinary: a migration, a stray sign-up feature and an authorisation model that trusted the network. For KYC teams, the lesson is about the archive itself. Every retained document image is exposure, so keep only what the rule requires, in the least sensitive form it allows, for no longer than it requires.

Cited sources

• DigiCert full incident report, Mozilla Bugzilla 2084460, 1 November 2026
• DigiCert preliminary incident report, Mozilla Bugzilla 2084460
• D-Trust: loss of archived RA records for S/MIME certificates at E.ON SE RA, Mozilla Bugzilla 2085547
• TWCA: unauthorised access to an RA server, Mozilla Bugzilla 2086949
• CA/Browser Forum TLS Baseline Requirements, section 5.5.2 retention period for archive
• CA/Browser Forum Code Signing Baseline Requirements, section 3.2.3.1 individual identity verification
• Money Laundering Regulations 2017, regulation 40 record-keeping
• 31 CFR 1020.220 customer identification programs for banks
• Regulation (EU) 2016/679, the GDPR, on EUR-Lex