DigiCert posted its full incident report in Mozilla’s public CA compliance tracker on 1 November 2026. The DigiCert breach, as the report describes it, is unauthorized read access to archived customer data. The company says its certificate authority services, CertCentral and DigiCert ONE were not affected. Mostly business contact details were exposed, plus identity documents for a small minority of accounts.
This playbook is for customers and their security teams. It turns the incident report into an order of work: who to warn, what to watch for, and what to check in your own accounts.
How Did the DigiCert Breach Make a Business System Readable?
DigiCert’s report traces the cause to an infrastructure migration on 4 February 2025. The system was moved from a network segment restricted by a VPN to an availability zone that was reachable from outside. A self-registration feature, meant for other products, came along with it.
Accounts created through that feature did not need multi-factor authentication and were read-only by default. They still had access to archived data. DigiCert says a managed security program reported on 21 June 2026 that accounts could be created from outside, and it verified this on 24 June. Its own investigation later placed the data access between 27 June and 2 July 2026.
DigiCert released an authorization fix on 2 July 2026. It confirmed the unauthorized access on 19 October 2026 and filed a preliminary report the next day. The report also says the first review on 18 June treated the case as an account-creation problem, not a data-access event.
What Should Customers Do, in What Order?
The order below starts with the question that decides everything else: did your organization send DigiCert identity documents? Step 2 rests on what the report says. The other steps are our advice, since the report does not say which customers are affected.
- Find out what you sent DigiCertAsk whoever manages your DigiCert account which representatives gave a name, business email, phone number or address. Check whether anyone uploaded a passport, driver’s licence or utility bill during validation.
- Keep your certificates in serviceDigiCert says active certificates remain valid and trusted, and customers need no action on them. Do not revoke or reissue certificates because of this notice.
- Warn the people on fileTell every named representative that their contact details were in scope. Ask those who supplied identity documents to watch their own accounts and credit records.
- Brief your mail and help desk teamsExpect messages that use DigiCert branding and the exposed names. Tell staff that a real notice will not ask for a password, a code or a document upload through a link.
- Check your DigiCert account yourselfOpen CertCentral by typing the address. Review the user list, the API keys and the recent sign-in activity, and remove users who left. DigiCert says customer login credentials remain secure, so this is routine hygiene.
- Treat validation calls and emails with careDomain and organization validation involves contact details. Confirm any unexpected request through the account, not through the message that asked.
Step 2 matters because the report states it plainly, and acting against it creates work for no gain. DigiCert says its CA systems run on their own secure network segments and were not reached. Our glossary entry explains what a certificate authority does.
How Will Attackers Use Names and Identity Documents?
The report does not say the data was published or sold. What we can describe is how this kind of data is normally used. A name, a work email and a phone number let a scammer write a convincing message that appears to come from a certificate vendor.
A message such as “your certificate validation failed, upload your passport again” is the likely shape of such an attempt. That is our reading, not a reported campaign. Our page on brand impersonation shows how these messages are built, and the article on identity documents offered in bulk shows what happens when scans reach criminal markets.
People who supplied a passport or licence face a longer risk than a password holder, because a document cannot be rotated. They should watch for new accounts opened in their name and treat requests to verify identity with suspicion. Your national identity authority or credit bureau can place a fraud alert where that service exists.
What Did DigiCert Change, and What Is Still Open?
DigiCert lists these steps as complete. It disabled self-registration, moved remaining endpoints to private addresses and reset passwords for business system users. It also added a security sign-off rule for network changes, ran a penetration test and set new alerts on file access and request volumes. Two items were still ongoing in the report, an internal audit and a review of account-creation alerts, both due on 6 November 2026.
The report does not give the number of people, organizations or documents involved. It also does not say how customers will be told individually. Until DigiCert publishes more, assume that any representative you named could be in scope.
What Does This Teach About Your Own Internal Systems?
The lesson in the report is one every team can test this week. DigiCert wrote that a network move should always get a security review, and that authorization must not rely on network position. Both apply to your own migrations.
List the internal tools that moved networks in the last two years and confirm that none answers from the internet. Check that every account-creation or self-registration endpoint is off where it is not needed. Our playbook on supplier exposure changes covers the same question from the vendor side, and our data breach response guide covers the notice and contact work. We will update this page when DigiCert publishes more about scope or about how it notifies customers.