← Blog
Incident analysis

The company that vouches for everyone else's identity forgot to check its own: the DigiCert breach

DigiCert verifies everyone else’s identity for a living. A server migration moved an internal system onto the public internet, an authorization flaw let self-registered accounts read archived customer data — identity documents included — and the first investigation closed the case before the reading started.

Ben Le, Founder · 6 November 2026 · 7 min read

DigiCert is one of the largest certificate authorities in the world. Its business is identity verification: when a website shows a padlock, there is a good chance DigiCert issued the certificate behind it. On November 5, BleepingComputer reported that DigiCert has told customers it suffered a data breach — and that the records exposed include the identity documents DigiCert itself collected to perform those checks.

The breach began with a migration. According to DigiCert's own incident report, published on Mozilla's Bugzilla platform, a server migration on February 4, 2025 mistakenly moved an internal business system out of a network segment reachable only through a VPN and into one the public internet could reach. The system contained a self-registration feature intended for other applications, so anyone on the internet could create an account on it — and an authorization flaw let those unassigned accounts read archived customer information in read-only mode.

The data involved is the kind that makes this breach different from an ordinary contact-list leak. DigiCert says the affected archive held a small portion of its archived customer data: names, business email addresses, phone numbers, and business addresses. For a small minority of accounts, the records also contained personal identification documents submitted during certificate validation — driver's licenses, passports, utility bills, or other documents carrying a name and address. DigiCert has not said how many people are affected. Cloud architect Fabian Bader shared a copy of his notification on X, objecting to the description of the incident as "limited".

The timeline is the part that should worry every security team, because it is a timeline of a system working almost correctly at every step. DigiCert first discovered unauthorized accounts on the exposed system in June 2026 and concluded they could not access customer information, because they were not assigned to an application — a reasonable inference from how the system was supposed to work, and a wrong one. A report through its managed security research program warned that external users could create accounts; DigiCert verified that on June 24 and deployed fixes. But it did not realize archived data had already been accessed. Only on October 12 did the company first suspect archive access, and on October 19 a further investigation confirmed an unauthorized account had read customer information between June 27 and July 2, 2026. In DigiCert's own words: "The incident was initially handled as an account-creation issue rather than a data-access event."

The boundaries matter too. The unauthorized account had read-only access: it could not modify records, approve certificate validations, or issue certificates, and logs showed no such activity. DigiCert's certificate authority services, CertCentral, and DigiCert ONE platforms were not compromised, and customer login credentials and issued certificates remain secure. None of that is in doubt — and none of it changes what was taken. Those documents are the raw material of impersonation, and they were readable by an account that should never have existed, through a system that should never have been reachable.

What actually failed

Three distinct failures stacked into one breach.

First, drift without detection. A migration moved a system across a network boundary — from VPN-only to internet-reachable — and nothing flagged the change for sixteen months. Network changes are among the most routine operations in any estate, and also among the most dangerous, because they silently rewrite who can reach what — a system safe by virtue of where it sat became unsafe the moment it moved.

Second, an authorization check evaluated once, at the wrong moment. The system's logic was that an account with no application assignment cannot access data — a statement about how accounts were created, treated as a guarantee about what they could do. The authorization flaw broke the guarantee, and nobody re-checked it at access time, the moment the check actually matters. The account was trusted because of how it came into being, not because of what it was doing.

Third, an investigation that stopped at the first plausible explanation. "Unauthorized accounts exist, but they can't reach data" is a finding that feels complete. It closed the case in June, and the case stayed closed while the data was being read in late June and early July. The evidence that would have corrected it was examined only in October, after the suspicion finally formed.

How Redthread is built for this class of failure

Mapping: DIRECT — Redthread's product addresses this failure class: an authorization decision made once and never re-verified at access time, a network change that quietly moved a system out of its protected segment, and an investigation that stopped at the first plausible explanation. The victim happens to be a certificate authority; the failure class is general.

This is the failure class Redthread's assessment platform is built to shrink: exploitable weaknesses and drift in your own estate, found with evidence and re-checked continuously.

The assessment platform (redthreadsec.com) is agentless and AI-native. It builds one context graph of your whole estate — the Redthread Flow — covering agents, applications, code, cloud accounts, identities, controls, and the data they can reach, so an internal system, the segment it sits in, and the identity documents behind it show up as one connected picture. The free self-serve estate scan (Assess & Consolidate) — nothing to install — shows your AI and agent footprint, shadow-AI, cloud posture and sensitive-data exposure (DSPM), and cross-cloud attack paths, ranked first. Our exploit-validation engine actually exercises weaknesses, pentesting AI applications and agents against the OWASP LLM Top 10 as mapped to MITRE ATLAS, with a reproducible proof of concept for every finding. Evidence, never inferred. CI/CD gating blocks merges that introduce proven attack paths, continuous re-assessment catches drift, and results roll up into reports and Letters of Attestation mapped to the frameworks your auditors ask about.

The Agentic Trust & Protection Platform — ATPP (trust.redthreadsec.com; in the console, Agent Trust & Enforce) applies the same principle to machine authority: cryptographic agent identity (SPIFFE) bound to builds, so identity is verifiably your code rather than a name or a static credential; call-time verification of identity and tool claims jointly, at the moment of use rather than at account creation; attenuating delegation with signed receipts, so authority can only narrow as it passes along; revocation that propagates when a tool drifts; signed trust-state events for orchestrators, gateways, and SIEMs; and a daily signed scan of the full MCP registry — our November 1 scan covered 54,513 servers and found 1,509 listing swaps — anchored in the public Sigstore Rekor transparency log, with our Enforce gateway, currently in preview, putting these checks in-path, and hooks for Claude Code and Cursor that check each MCP tool call against the server's signed claim before it runs. Signing keys live in a separate signer service, sealed in a cloud vault — requestable, never readable — and trust events go to a ledger the database itself refuses to update, delete, or truncate.

What Redthread does NOT claim

Plainly: Redthread was not inside DigiCert's estate, did not assess DigiCert, and we cannot promise our exploit-validation engine would have found that authorization flaw or flagged that migration. ATPP is an agent-identity layer, not a certificate-authority auditor. We also do not claim the number of affected people — DigiCert has not given one, and any figure circulating today is a guess. What we claim is structural and testable: weaknesses proven by exercise rather than inferred from scans, drift re-checked continuously, and authority verified at the moment of use, shrink both the detection gap and the blast radius that made this breach what it was. If you have ever submitted identity documents to DigiCert, treat those documents as exposed and watch for impersonation attempts built from them.

Build it with us

We are opening two to three founding design-partner slots: a free 30–45-day pilot — estate scan, cryptographic identity and call-time verification on one live workflow, detect-only, plus the attestation evidence your auditors keep asking for — with deeply discounted, locked founding pricing after. If an internal system in your estate holds identity documents — and it does — start with the free estate scan at redthreadsec.com, or come straight to us about a design-partner slot.

Sources: BleepingComputer, "DigiCert data breach exposes customer information, identity documents," Nov 5, 2026; DigiCert incident report on Mozilla's Bugzilla platform, posted Nov 1, 2026, as summarized by BleepingComputer and SC Media, Nov 5, 2026.

Keep reading

More from the blog.

Agentic Trust & Protection Platform
Agentic Trust & Protection Platform: an identity, a record, and — soon — a checkpoint for every AI agent
What ATPP gives an agent today, what the ATPP Enforce preview adds, and — just as important — what we do not yet claim.
Platform
Agentless and graph-first: why we start with a map, and where the time and money go
Installing agents everywhere and triaging flat lists of findings are the two biggest hidden costs in security tooling. Here is how an agentless graph removes them.
Pentesting
What an AI penetration test costs — and what it does not replace
A manual pentest is a large, infrequent purchase. Autonomous agents make it small and frequent. The honest comparison, including the parts humans still do better.