DigiCert breach: a system moved off VPN exposed customer identity documents for 16 months

DigiCert has disclosed that outsiders accessed an internal business system holding information customers submitted to prove their identity. For a small minority of customers, that included copies of driver’s licences, passports and utility bills. The system became reachable from the internet in February 2025, when it was moved out of a VPN-restricted network. DigiCert did not spot the problem until June 2026, and it took until October to confirm that data had been read. Certificate operations were not affected, but the stolen data is well suited to convincing, targeted phishing of DigiCert customers.

Quoi	Unauthorized access to a DigiCert business system that stores customer-provided validation information
Cause première	4 Feb 2025 infrastructure migration moved the system from a VPN-restricted segment into an externally reachable zone; a self-registration feature without MFA let outsiders create accounts that could read archived data
Detected	18 June 2026 (non-DigiCert accounts noticed); 21 June 2026 (external account creation flagged by a managed security programme)
Confirmed access window	27 June to 2 July 2026; confirmed and declared reportable on 19 Oct 2026
Data exposed	Names, business emails, phone numbers, business addresses; for a small minority, driver’s licences, passports, utility bills or similar documents
Not affected (per DigiCert)	CA systems and certificate issuance or revocation; validation records; customer login credentials
Number affected	Not disclosed
Statut	Fixed 2 July 2026; affected customers notified; law enforcement informed; post-mortem filed as Mozilla Bugzilla bug 2084460

Ce qui s'est passé

According to DigiCert’s incident report on Mozilla Bugzilla, the affected system stores information customers provide to validate their identity. That is the evidence a certificate authority collects before it issues organisation-validated or extended-validation certificates. On 4 February 2025, an infrastructure migration moved the system from a VPN-restricted network segment into an availability zone that could be reached from the internet.

The move exposed more than a login page. The system’s account-management platform had a self-registration feature built for other use cases, and the migration made it available on this system too. Accounts created through it did not require multi-factor authentication, even though DigiCert normally does. They were read-only by default, but because of a gap in the authorization model, an account with no assigned application could still read archived data. SecurityWeek, which reviewed the same disclosure, says attackers used such a self-created read-only account to reach the archive.

The Bugzilla timeline shows a slow escalation:

• 18 June 2026: staff noticed non-DigiCert accounts but wrongly concluded they had no data access, and put the system behind a web application firewall (WAF).
• 21 June: a managed security programme report flagged possible external account creation. DigiCert verified it on 24 June.
• 27 June: start of the confirmed data-access window.
• 2 July: an authorization patch, which returns HTTP 401 to accounts with no assigned application, went to production and ended the access. On 9 July the WAF limited the hostnames to VPN traffic.
• 12 October: DigiCert first suspected that archived data had been read.
• 19 October: the 27 June to 2 July access window was confirmed and the incident was declared reportable. A preliminary report followed on 20 October.

One detail stands out: the confirmed access began après DigiCert’s team had already seen the unfamiliar accounts. DigiCert’s own lessons-learned section admits the incident was first handled as an account-creation issue rather than a data-access event.

DigiCert says the access could not write records, act as a validation approver, or issue or revoke certificates. It also says its CA systems run on separate network segments. A spokesperson told The Record there was “no evidence of misuse of the information involved”. The company has not said how many customers were affected. On Bugzilla, it describes the affected data as a small proportion of the archive.

Why the 16-month exposure window matters

About 16 and a half months passed between the migration on 4 February 2025 and the first sign of trouble on 18 June 2026. For that whole period, an internal system holding identity documents sat on the internet with an open self-registration path and no MFA on the accounts it created. DigiCert’s post-mortem names three causes:

• The migration was handled as an infrastructure change, not a security change, so it never got a security review or sign-off.
• Monitoring was not reassessed after the move, so there was little alerting on new account creation or request volume.
• The authorization model did not account for self-registered accounts, and reviewers assumed those accounts could read nothing.

DigiCert says retained logs and audit tables let it reconstruct the access window. Its confirmed window covers only six days at the end of the exposure period. The public material we reviewed does not say whether DigiCert’s logs reach back to February 2025, or how it ruled out earlier access. Customers should therefore treat the confirmed window as the minimum exposure and keep that question open until DigiCert answers it.

Once data is copied, the window stops mattering for the attacker. A passport or driver’s licence stays valid for years, and business contact details linked to a known certificate-buying organisation are still useful long after a password reset. On social media, as The Record reported, people worried that attackers could link identity documents to specific certificates and their owners.

What DigiCert customers should do now

DigiCert has notified affected customers by email. The steps below are MAG212 recommendations, not DigiCert guidance, and are listed in priority order.

• Expect validation-themed phishing that uses your real details. Messages may quote your name, title, phone number and company address and claim that a certificate needs revalidation, that a document has expired, or that a domain control check is pending. Real contact details do not prove a message is genuine.
• Verify every request out of band. Do not click links or call numbers in unexpected validation emails, texts or calls. Sign in to your CA account by typing the address yourself, or call your account manager on a number you already have on file.
• Brief the people DigiCert validates against. That means certificate approvers, organisation contacts, finance and the help desk. Social engineering aimed at them may ask for domain changes, DNS records, payment detail updates or new approvers.
• Watch Certificate Transparency logs for unexpected certificates on your domains, and set CAA records so that only the CAs you use can issue for them. DigiCert says certificate issuance was not affected. This step is about catching downstream social engineering at any CA.
• Take identity-theft steps if your documents were included. Consider credit freezes or fraud alerts with the national credit bureaus where you live. Watch for new accounts in your name. Ask your passport or licensing authority whether the document should be reported or replaced, and keep DigiCert’s notification as evidence.
• Ask DigiCert directly which fields and documents were held for your organisation, and whether access before 27 June 2026 has been ruled out.

Lessons for any organisation moving systems off VPN

Moving an application off the VPN is common, and it is often the right call. DigiCert’s own conclusion is that “authorization for a business system must not be delegated to its network position.” In practice, many internal applications rely on the VPN as their main control, and that control disappears the moment the network changes. DigiCert’s fixes include security sign-off and asset-inventory updates for network changes, a named security owner for the system, per-endpoint authorization, and alerts on file access and request volume routed to its SOC.

MAG212 recommendation: treat any change that alters reachability as a security change, and check it continuously, not just once.

• Gate reachability changes in change management. Any ticket that moves a workload between segments, zones, load balancers or public IPs needs a security reviewer, an updated asset inventory and a list of every endpoint that becomes exposed, including registration, password-reset and API paths.
• Run external attack-surface monitoring. Scan your public IP ranges and DNS on a regular schedule, compare the results with an approved list of internet-facing services, and alert on anything new. A new hostname or open port that is not on the list should open a ticket automatically.
• Audit identity features before exposure. Turn off self-registration unless it is required, enforce MFA on every account path, and test what a freshly created account with no roles can actually read.
• Re-baseline detections after migrations. Alert on account creation from external sources and on unusual read volume. Treat unknown accounts as a possible data-access incident until logs prove otherwise.
• Minimise and age out sensitive documents. Identity documents collected for one-time validation should be retained only as long as policy or regulation requires.

A simple external check can catch drift between scans. Here is an example of comparing what answers on your public range against an approved baseline:

# Scan your own public ranges only (authorised assets)
nmap -Pn -p 80,443,8080,8443 -oG - -iL public_ranges.txt \
  | awk '/open/{print $2}' | sort -u > exposed_today.txt

# Hosts answering today that are not in the approved baseline
comm -13 approved_internet_facing.txt exposed_today.txt

What we still don’t know

• How many customers were affected, and how many records included identity documents. DigiCert has offered summary statistics to root programme representatives but has not published them.
• Whether logs cover the full period from February 2025, and how earlier access was ruled out.
• Who was behind the access, and whether they have contacted DigiCert. The company declined to say.
• What prompted the suspicion on 12 October. A Bugzilla commenter asked this, but no answer was visible when we reviewed the bug.

Related on MAG212 CYBER

• The Trusted Path: MAG212 CYBER Daily, November 8, 2026

Sources

• The Record: “Certificate authority DigiCert reports data breach involving business customer info”, 6 November 2026
• Semaine de la sécurité: “DigiCert Data Breach Impacts Business Customer Information”, 6 November 2026
• Mozilla Bugzilla: Bug 2084460, “DigiCert: Unauthorized access to business system” (preliminary report 20 October 2026; reviewed 8 November 2026)

Written and edited by El Mostafa Ouchen for MAG212 CYBER. Facts verified against the sources above as of 8 November 2026.