DigiCert’s breach began as a routine network move. Nobody asked what it put on the internet.

01 What DigiCert has confirmed

Two details matter for anyone running a smaller estate. The system sat reachable from the internet for more than 16 months before anyone noticed. And the first sighting of strange accounts was filed as an account-creation problem. DigiCert told customers the incident “was initially handled as an account-creation issue rather than a data-access event” [ BleepingComputer ] . It took about four months to establish that data had been read.

DigiCert has not said how many customers were affected. It says summary figures are available to root programme representatives on request [ DigiCert incident report ] . We make no guess at who held the account.

02 Filed as infrastructure work, never reviewed for security

DigiCert lists three contributing factors. The network change had no security review of the attack surface it created. Monitoring was not reassessed after the move, so nobody got an alert when accounts were created from outside. And the permission model assumed that an account with no application assigned could see nothing, when it could read the archive [ DigiCert incident report ] .

The self-registration page was never meant for this system. It came from the shared customer account platform, built for other DigiCert products. Behind the VPN it was harmless, because only staff could reach it. On the internet it was an open door, with no MFA, to an archive of identity documents. Start with Identity put the root problem plainly: self-registration should not have been switched on for a system that never needed outside users [ Start with Identity ] .

DigiCert wrote its own lesson in one sentence: “Network accessibility changes to internal systems should always require a security review.” A second line in the report goes further: “Authorization for a business system must not be delegated to its network position” [ DigiCert incident report ] . In plain terms, an internal tool must check who you are even when it thinks only colleagues can see it.

03 What an external test looks for

An external network penetration test starts with no inside knowledge, only your company name, domains and IP ranges. The first day is spent finding everything that answers. On an estate shaped like DigiCert’s, the work runs in a fixed order.

1. Enumerate hostnames. Certificate transparency logs, DNS records and IP range scans list every name and address that responds, including ones the IT team believes are internal.
2. Flag what should not be there. A login page for a back-office tool on a public address is a finding by itself, before anyone types a password.
3. Try the front door. A “register” or “create account” link on a staff-only system is an invitation. A tester follows it, with your written permission, and creates an account.
4. Test what a nobody can see. A fresh account with no role should get nothing. The tester checks every page and API call that account can reach. Here, that step would have hit the archive.

That sequence is ordinary work for a tester, and it costs an attacker nothing. DigiCert added a penetration test after authorisation and network changes to its own action list, and completed one on 31 August 2026 [ DigiCert incident report ] . The value of an external test lies in running it before the stranger signs up.

04 A ten-minute check on your own estate

You can do a rough version of the first day yourself. It will not replace a test or our free external exposure audit, but it tells you whether you have a DigiCert-shaped gap right now.

If step two or three turns up a surprise, treat it the way DigiCert eventually did: assume data was read until logs prove otherwise. If the tool holds customer data or identity documents, that question goes to whoever handles your data protection obligations, the same day.

05 Three fixes for every migration

DigiCert’s action list runs to 13 items. For a company of 20 to 500 people, three of them carry most of the weight.

1. Put a security gate on network changes. Any change that alters what can reach a system needs a security sign-off before it goes live. DigiCert now requires security sign-off and an asset inventory update for network changes. A small team can do it with one mandatory question on the change ticket: does this make anything reachable that was not reachable before?
2. Scan from the outside after every migration. Run an external attack surface scan the week a migration finishes, and compare the result with the list from before the move. Anything new that answers is either intended and documented, or it gets closed. Repeat on a schedule, because estates drift.
3. Switch off self-registration on internal tools, and deny by default. Staff accounts should come from your identity provider, created by an admin. An account with no role should see nothing, and every account should need MFA. Alert on new accounts created from outside your network.

None of this needs new software. It needs someone to own the question. DigiCert’s last fixes included assigning a single named owner for the system’s security [ DigiCert incident report ] . Name yours before the next migration starts.

If you are a DigiCert customer, expect phishing that uses your real contact details and order history. Start with Identity advises confirming any certificate or validation request through your DigiCert account, never through a link in an email [ Start with Identity ] . Our pretexting field note shows how attackers turn exactly this kind of data into a convincing phone call.

Planning a cloud move, a hosting change or a firewall swap this year? Book a post-migration penetration test from the outside for the week after it lands. You get the list of everything a stranger can reach, what each item leads to, and the fix for each, while the migration team still remembers what they changed.