How Internal Systems Become Internet-Exposed: The DigiCert Breach Explained in Plain Language

The short version

Imagine a company keeps old paperwork in a back room. One day, during a refit, the builders move the back room’s door so it opens straight onto the street. Nobody notices. The door has a sign-up sheet that lets anyone write their name down and walk in. For sixteen months, nobody does. Then somebody does.

That, stripped of jargon, is what DigiCert — one of the world’s largest issuers of the certificates that put the padlock in your browser — disclosed this week. It is also a near-perfect illustration of how internal systems become internet-exposed without anyone deciding they should be. This explainer walks through what happened, why this kind of mistake is so common, and what any organisation — not just certificate authorities — can do about it.

What happened at DigiCert

Based on DigiCert’s statement as reported by SecurityWeek and The Register (6 November 2026):

• February 2025: an internal archiving system — a place where older customer records were kept — was moved to a different part of DigiCert’s network during a migration. In its new location it was reachable from the internet. SC Media describes the root cause as a server migration error.
• The system allowed self-registration. Anyone who found it could create their own account. Those accounts were read-only and were not protected by multi-factor authentication (MFA).
• 27 June – 2 July 2026: an attacker created an account and read archived records.
• October 2026: DigiCert detected the access and began investigating.
• What was exposed: business customers’ names, email addresses, phone numbers and business addresses, and for some customers, identity documents such as driving licences, passports and utility bills that had been submitted during certificate validation.
• What was not affected: DigiCert says the account could not issue certificates or act as a validation approver, and its certificate authority systems were not touched. The certificates protecting websites remain trustworthy. DigiCert has not said how many customers were affected.

This is separate from an earlier 2026 incident involving DigiCert’s support portal and code-signing certificates. Today’s story is about something more mundane, and that is why it is worth understanding.

Why this is not really about DigiCert

It is tempting to read this as “a big company got careless”. The more useful reading is that nothing in this chain looked dangerous on its own:

1. Moving a system between network segments is routine. Networks are reorganised constantly — during cloud migrations, data-centre moves, mergers, or simple tidying up.
2. Self-registration is a convenience feature. Inside a closed network, letting staff create their own read-only accounts saves helpdesk tickets.
3. No MFA on a read-only archive feels proportionate when you believe only employees can reach it.
4. An archive is the kind of system nobody owns day to day. It is not a product, it is not on anyone’s roadmap, and it rarely appears in a risk review.

Each decision was reasonable for the world it was made in. The problem is that step 1 quietly changed the world, and steps 2–4 were never re-examined. Security people call this configuration drift: the gap between what you think is true about your systems and what is actually true today.

The sixteen-month window

The part of this story that should make every IT manager pause is the timeline. The system was reachable for roughly sixteen months before anyone used it, and the use itself lasted under a week. Detection came months after that.

In other words, the defenders had a year and a third in which a single check — “is this thing reachable from the internet, and should it be?” — would have closed the door before anyone walked through it. Attackers do not need to be clever when they can be patient. Automated scanners sweep the entire internet every day looking for login pages, and an exposed portal that says “create an account” is about as inviting as it gets.

What this means for ordinary organisations

You probably do not run a certificate authority. You almost certainly do have:

• Old systems nobody owns — an archive, a test server, a reporting tool from a project that ended.
• Network or cloud changes that happen faster than anyone updates the documentation. In the cloud, one changed security-group rule or a storage bucket switched to public does the same job as DigiCert’s segment move.
• Convenience features — open sign-up, shared links, “anyone with the link can view” — that were safe only because of where the system sat.

And if your data was in such a system, the risk does not stop at the breach. Real names, phone numbers and business addresses make phishing far more convincing. DigiCert customers should expect emails that look like genuine certificate-renewal notices, because the attacker now knows exactly who handles certificates at their company.

The CloudShieldSecure perspective

At CloudKonsult, we think the most important lesson here is about timing. The breach became possible in February 2025, not in June 2026. A one-off audit or an annual penetration test would most likely have missed the window; a periodic review is a snapshot of a moving target.

That is the reasoning behind CloudShieldSecure’s continuous approach to cloud posture: rather than asking “were we secure at the last review?”, it watches for the change itself — a resource newly reachable from the internet, an identity setting that lets unknown users in, a login without MFA where policy expects it — and raises it the day it happens, with the context needed to decide whether it was intended. The goal is simple: shrink a sixteen-month window to a sixteen-hour one.

We wrote about a related blind spot — access you have granted to outside parties — in our piece on third-party cloud access reviews after the Northflank breach. Both stories share a root: access nobody is actively looking at.

Recommended actions

You do not need a security team to start on these.

1. Make a list of everything you have that faces the internet. Ask your IT provider or cloud admin for it. If nobody can produce one quickly, that is your first finding.
2. For each item, name an owner. A system without an owner is a system nobody will notice drifting.
3. Turn off self-registration on anything that holds customer or employee data, unless it is genuinely meant for the public.
4. Require MFA everywhere a login exists — including “read-only” accounts. Reading is often all an attacker needs.
5. Re-check exposure after every migration or network change, not just at the annual review. Add “what became reachable?” to your change checklist.
6. Clean out archives. If you hold copies of passports or driving licences you no longer need, delete them. Data you do not keep cannot leak.
7. If you are a DigiCert customer, treat unexpected certificate-renewal or validation emails with extra suspicion and verify through your account portal, not links in the email.

Sources & references

• SecurityWeek — DigiCert Data Breach Impacts Business Customer Information (6 Nov 2026)
• The Register — DigiCert admits 16-month security lapse exposed customer information (6 Nov 2026)
• SC Media — DigiCert reports data breach following server migration error