DigiCert Data Breach: A Server Migration Exposed Customer Records and ID Documents, What Is Confirmed and What to Do

DigiCert, a certificate authority that issues the security certificates behind website padlocks and signed software, says a February 2025 server migration left an internal system holding customer identity-verification records reachable from the internet. Someone used it to read part of that archive between June 27 and July 2, 2026. If your company has bought certificates from DigiCert, the names, work emails and phone numbers of the people who placed those orders may be in that data. For some customers, copies of a driver's license, passport or utility bill may be in it too.

DigiCert says the certificates themselves are not affected. For most companies, the bigger risk is what an attacker can do with an accurate list of the people who manage your certificates and how to reach them.

What happened in the DigiCert data breach

DigiCert published its account on Bugzilla, the public tracker where certificate authorities report incidents to Mozilla's root store program. The preliminary report is dated October 20, 2026. The full report followed in early November.

According to DigiCert:

• On February 4, 2025, an infrastructure migration moved an internal business system from a network segment reachable only by VPN to one reachable from outside. That exposed an account-registration page meant for other internal applications.
• Monitoring and alerting were not reassessed after the move, so nobody noticed the exposure.
• Accounts created through that page did not need the multi-factor authentication (MFA) DigiCert otherwise requires, and the system's permission checks did not account for them. A self-registered account could read archived customer data, read-only.
• On June 18, 2026, staff spotted non-DigiCert accounts on the system, concluded they could not reach any data, and put the system behind a web application firewall that blocked new sign-ups from outside. On June 21, DigiCert's managed security research program reported that outsiders could create accounts.
• An account that already existed read archived customer data from June 27 to July 2, 2026. DigiCert released an authorization fix on July 2.
• DigiCert first suspected the data access on October 12 and decided on October 19 that it was a reportable event. DigiCert says it first treated the problem as an account-creation issue rather than a data-access event.

What data was exposed in the DigiCert breach

DigiCert says the system archives information used to check the identity of customer representatives. Most of the affected records are business contact details:

• Names
• Business email addresses
• Phone numbers
• Business addresses

For what DigiCert calls a minority of customer accounts, the records also included documents customers had sent in during validation, such as a driver's license, passport or utility bill. BleepingComputer reports that DigiCert is still reviewing those documents to work out who was affected, and that it has started sending breach notices.

What is confirmed and what is not known

Confirmed by DigiCert: the migration date, the exposure, the missing MFA on self-registered accounts, the June 27 to July 2 access window, and the types of data the system held.

Claimed by DigiCert and not independently verified: that the access was read-only and could not approve validations or issue certificates; that the certificate authority systems, CertCentral and DigiCert ONE were not affected; that customer login credentials and issued certificates are still secure; and that no certificates were issued, changed or revoked as a result.

Not known: how many customers or people are affected, how many unauthorized accounts existed, who was behind the access, and whether data was only viewed or also copied. DigiCert says it will share summary statistics with root program representatives on request. A public request for numbers had not been answered at the time of writing. The report says DigiCert confirmed the access from "file access and request volumes" but does not say whether files were downloaded.

Is my SSL certificate affected?

Based on DigiCert's report, no. DigiCert says customers do not need to do anything about active certificates or their ongoing use of its services, so there is nothing to reissue or revoke. The steps that matter here are about people and phishing, not the padlock on your website. For a wider check of how your site looks from the internet, see whether your live website is locked.

What to do this week

How a server migration can expose an internal system

The root cause here is ordinary. A system that was safe because it sat behind a VPN was moved somewhere the internet could reach, and nobody reviewed the change for security. A sign-up page that did no harm when only staff could see it became an open door with no MFA.

The same thing happens in cloud moves, hosting changes and data center consolidations in every industry. DigiCert's own fixes make a good checklist for any company network:

• Require security sign-off for any change to network access. DigiCert has now made this a policy.
• Re-check monitoring and alerting after every migration, not just whether the app still works.
• Turn off self-registration on internal tools unless you really need it.
• Make every account, including self-registered ones, pass MFA and get an explicit role before it can see any data.
• Scan your own public IP addresses and hostnames from outside, so you find exposed systems before someone else does.
• Give each system one named owner who is responsible for its security.

If you run your own servers, our self-hosting and infrastructure work is built around keeping internal tools off the public internet. For the ownership question, see who is patching the software that runs your business.

Why this matters for a business

The people who manage a company's certificates can often approve domain validations, change DNS and log in to hosting accounts. A list of those people with their direct phone numbers and work emails is valuable to a phisher. An email that looks like it comes from DigiCert and mentions a real order is far more convincing than a generic scam. For anyone whose ID documents were stored, the exposure is personal and lasts far longer than a password reset.

This is also a reminder that security vendors hold your data too. In the eMudhra certificate compromise, the problem was broken keys. Here it was an ordinary internal tool.

DigiCert breach questions people are asking

Was DigiCert hacked?

DigiCert confirms that someone got unauthorized access to an internal business system after a migration made it reachable from the internet. It says its certificate systems were not affected.

Do I need to replace my DigiCert certificates?

No. DigiCert says customers do not need to do anything about active certificates, and that no certificates were issued, changed or revoked because of this incident.

What information was exposed?

Mostly names, business emails, phone numbers and business addresses. For some customers, it also included ID documents such as driver's licenses, passports or utility bills.

How many people were affected?

DigiCert has not said publicly. It describes the affected data as a limited part of its archive.

When did the DigiCert breach happen?

The system was exposed starting February 4, 2025. Data was read between June 27 and July 2, 2026, and DigiCert reported the incident on October 20, 2026.

Were passwords stolen?

DigiCert says customer login credentials are still secure. It reset the passwords of all users of the affected business system.

The bigger lesson

Most breaches do not start with a clever exploit. They start with a change nobody reviewed: a server moved, a firewall rule loosened, a forgotten sign-up page. Every migration is a security change and should be checked like one.

Want a second set of eyes on your network or migration plan? See security hardening or get a quote.

Get security alerts by email, with the free checklist, at security alerts.

Sources: DigiCert incident report, Mozilla Bugzilla 2084460; BleepingComputer.