DigiCert Says a Server Migration Exposed an Internal System for 16 Months, and the First Alert Was Filed as an Account Issue. How Would Your Team Classify the Same Signal?

DigiCert, one of the largest certificate authorities, has notified customers of a data breach that began with a server migration in February 2025, when an internal business system that had been reachable only over VPN was exposed to the internet. According to BleepingComputer's report, published 5 November 2026, an unauthorized account later read archived customer information. DigiCert has not said how many people are affected.

What happened

The reported sequence, from DigiCert's notification and incident report:

• February 2025: a server migration exposes the internal system to the internet.
• June 2026: DigiCert finds unauthorized accounts on the system. It concludes they could not reach customer data because they were not assigned to any application.
• Later, date not given: a report through DigiCert's managed security research program warns that external users can create accounts. DigiCert deploys fixes but does not realize archived data has been accessed.
• 19 October 2026: further investigation confirms an unauthorized account accessed customer information between 27 June and 2 July 2026.

The system included a self-registration feature intended for other applications. Behind the VPN that was harmless; once exposed, outsiders could create accounts. The accounts were not tied to an application, but an authorization flaw let them read archived customer data in read-only mode.

DigiCert's own report puts the process failure plainly: "The incident was initially handled as an account-creation issue rather than a data-access event."

What was exposed

For the affected portion of archived data: names, business email addresses, phone numbers and business addresses. For some people, identification documents such as driver's licenses, passports and utility bills, "if provided." DigiCert is still reviewing those documents to determine who is affected and says it will notify them when that is finished.

What DigiCert says was not affected

DigiCert says the unauthorized account had read-only access and could not modify records, approve certificate validations or issue certificates. It says CertCentral and DigiCert ONE were not compromised, and that customer login credentials and issued certificates remain secure. Those are DigiCert's statements; the reports we reviewed do not include independent verification.

DigiCert has restricted access to the system, disabled self-registration and added access controls.

Why the timeline matters

The data access happened over about five days in mid-2026, but the exposure window was roughly 16 months. Two things stand out:

1. A migration changed what was reachable, and nothing flagged it. The system's safety depended on network position, not on its own authorization checks. Moving servers removed the position.
2. The first signal was classified by its surface, not its consequence. An unexpected account on an exposed system was handled as an account-hygiene problem. The question that would have changed the response is what that account could read, and what it had already read.

What to check in your own environment

1. Compare pre- and post-migration reachability. For anything moved in the last two years, confirm which internal systems now answer from the internet.
2. Look for self-registration on internal tools. Sign-up or invite features built for other applications are easy to forget.
3. Test authorization, not just authentication. Can an account with no application assignment read anything? Ask for the answer in logs, not from the developer's memory.
4. Hunt for read activity, not only changes. Read-only access leaves no modified records, so you need access logs from the time unexpected accounts appeared.
5. Re-triage old tickets. Any prior "unexpected account" or "unusual sign-up" closed as hygiene deserves a second look with the question: what did it touch?
6. If you are a DigiCert customer, watch for the notification, and treat any identity documents you supplied as potentially exposed.

How Obiguard SOC fits

The failure in this case was not a lack of data; DigiCert found the accounts in June 2026. It was the step between "this is odd" and "this is a data-access event." Obiguard SOC is our security operations service, and that triage step is where analysts add the most. When an unexpected account appears, they ask what it is permitted to read and check access logs for that account's activity, and they escalate on consequence rather than on the alert's category label. A second reviewer does not prevent a migration mistake, and SOC cannot reconstruct logs that were never kept. It does shorten the time between a weak signal and the question that matters. For a related look at spotting unusual authentication activity, see our mSecure analysis.

Sources

• BleepingComputer: DigiCert data breach exposes customer information, identity documents