AW Dev Rethought Flash: DigiCert Breach Exposed Identity Documents, Not Certificates

DigiCert confirmed yesterday that an unauthorised party accessed archived customer records held in an internal business system. The first question anyone asks about a certificate authority breach is whether the PKI failed. It didn’t.

Certificate issuance, CA services, CertCentral, DigiCert ONE, customer login credentials and issued certificates were all unaffected. Logs showed no certificate issuance, validation or revocation tied to the intruder, and the account used could neither modify records nor approve validations. This is a corporate data breach at a PKI company, not a failure of the PKI — a distinction worth holding as coverage spreads.

What it was instead: an exposure that sat open for seventeen months, got noticed and dismissed nine days before the data was taken, and stayed unannounced for four months after the hole was closed.

What Was Exposed

Archived customer contact records — names, business email addresses, telephone numbers and company addresses.

For a small minority of accounts, something with a much longer tail: the verification documents customers submitted during validation. Passports. Driver’s licences. Utility bills.

DigiCert has published no count and describes the archived data as a small proportion of its records. It is notifying affected individuals directly, and says final exposure auditing and account-monitoring reviews were still in progress at the time of disclosure — so the scope announced yesterday may not be the final one.

Seventeen Months From One Migration

On 4 February 2025, an infrastructure migration moved the system out of a VPN-restricted network segment and into an externally accessible availability zone.

That move did something nobody noticed. The system had inherited a self-service registration endpoint from an account management platform used elsewhere in the business — entirely harmless behind a VPN, where everyone who could reach it already belonged there. Once the network segment changed, anyone on the internet could create an account.

Those accounts had no MFA. They had no application assignment. And they carried default read-only permissions that reached archived customer records.

The migration didn’t introduce a vulnerability. It changed who could reach one that had been sitting there, safely unreachable, the whole time.

This is the part that generalises past DigiCert. Reviewing a migration for correctness is standard — does the service still run, does the data still arrive. Reviewing it for reachability, for what the internet can now touch that it couldn’t yesterday, is not. The configuration was identical before and after. Only the blast radius changed.

Seventeen months passed.

18 June: They Saw It and Explained It Away

On 18 June 2026, DigiCert’s team noticed non-employee accounts in the system.

They investigated. They reasoned that accounts without an assigned application could not access data. They concluded it was benign.

On 21 June, an external security research programme independently reported the registration issue. Between 27 June and 2 July, an unauthorised party accessed customer data using exactly those accounts. The authorisation patch — rejecting accounts with no application assignment outright, returning a 401 — shipped on 2 July.

The detection worked. The reasoning didn’t.

That is the most transferable failure in the whole incident, and every engineer reading this has done it. The anomaly surfaced. Someone competent looked at it, built a plausible account of why this particular instance was harmless, and closed it out. The explanation rested on a single assumption nobody tested: that “no application assigned” meant “no data access.”

Nine days of warning. What failed wasn’t the tooling. It was confidence.

Then Four Months of Silence

The authorisation gap closed on 2 July. DigiCert confirmed a reportable breach on 19 October. The public learned about it on 5 November.

Some of that is defensible. Establishing what an intruder actually touched takes forensic work, and declaring a reportable breach before you understand its scope creates its own problems. Regulatory notification clocks typically start at confirmation, not at access.

But the people whose passports and driver’s licences sat in that archive spent those months not knowing. Nothing in the public record suggests the scope was genuinely unclear for fifteen weeks — the access window was six days, and the affected system was a single archive.

The exposure lasted seventeen months. The theft took six days. The silence lasted four months.

The Default Nobody Specified

Beneath all of it sits a third failure worth naming separately.

The authorisation model was built around users who belong to applications. An account with no application assignment wasn’t a configuration anyone designed — it was a state the system permitted but nobody had reasoned about. So it inherited whatever the fallback happened to be, and the fallback was read-only access to archived customer records.

In the designers’ heads, “read-only, no application” meant nothing at all. In production it meant the entire archive.

Every permission system has one of these. The combination nobody enumerated. The role with no explicit grant. The account type that exists because the schema allows it rather than because anyone chose it. They survive review because reviews examine the cases people thought of.

To DigiCert’s credit, its own root-cause list names all three of these plainly — inadequate migration security review, insufficient account-activity monitoring, and an authorisation model that did not anticipate self-registration. That is a more candid accounting than most companies publish.

What to Do If You’re a DigiCert Customer

Nothing in your certificate infrastructure needs touching. No rotation, no reissuance, no revocation. That genuinely is not the exposure here, and anyone telling you otherwise has misread the story.

Assume your business contact details are in someone’s hands and adjust your phishing posture accordingly. Attackers holding real names, real company addresses and real phone numbers write far more convincing mail than attackers working from scraped lists. If your team receives anything referencing your DigiCert relationship over the coming weeks, verify through the portal rather than through the message.

If your organisation submitted identity documents during validation, that exposure outlives the incident. Find out who on your team handled validation and what they uploaded. You can rotate a credential. You cannot rotate a passport scan.

DigiCert has disabled self-registration, moved remaining endpoints behind private-IP load balancers, reset business-system passwords and added file-access alerts. The hole is closed. What went through it is not coming back.