DigiCert Data Breach: 5 Lessons From a Forgotten Archive

The DigiCert data breach is a useful reminder that attackers do not always need clever exploits, because sometimes they just walk through a door someone forgot to lock.

DigiCert, one of the biggest certificate authorities on the internet, confirmed in early November that an internal system holding archived customer records had been reachable by unauthorized accounts. The company says its certificate issuing services were not affected. Still, the story of how it happened is worth reading closely, because the mistakes involved are common ones.

What happened in the DigiCert data breach

According to Cybersecurity News, DigiCert confirmed unauthorized access on October 19, 2026 and filed a preliminary incident report the next day. The exposed system held archived customer records: names, business email addresses, phone numbers and business addresses. For a small minority of accounts, it also held passports, driver’s licenses, utility bills or similar documents.

The timeline is the interesting part. On February 4, 2025, the system was migrated out of a VPN-restricted network segment. That move accidentally made it reachable from the internet, and nobody ran a security review. An account registration feature then let new accounts sign up without the multi-factor authentication that staff accounts require. Those accounts got read-only access to archived data because of a gap in permission checks.

Staff spotted non-DigiCert accounts on June 18, 2026. An early review wrongly concluded they could not reach data. Unauthorized access ran from June 27 to July 2, when an authorization fix shipped. Suspicion about archived data only came on October 12.

DigiCert has not published how many people or organizations were affected. It says notifications will follow once it finishes reviewing identity documents.

Lesson 1: A network move is a security event

Let me be direct: this started with a migration. Someone moved a system, the old network protections went away, and no review caught it. Treat every migration, whether to a new VPC, a new cloud account or a new subnet, as a change that needs a security sign-off. Ask one simple question: who can reach this now that could not before?

If you are planning a cloud move, build that question into the checklist. It costs ten minutes and can save months of pain.

Lesson 2: Internal tools need their own authorization

DigiCert’s own takeaway was that internal tools need explicit authorization checks even when network restrictions are expected to protect them. That is solid advice. The VPN was doing the real work, and once it was gone, nothing else stood in the way.

This is the heart of zero trust. Assume the network is hostile. Make every service verify who is asking and what they are allowed to see, no matter where the request comes from. The CISA Zero Trust Maturity Model is a decent starting point for planning that shift.

Lesson 3: Self-registration and MFA must go together

Open sign-up is fine for a public product. It is dangerous when it touches a back-office system. Here, new accounts skipped the MFA that staff accounts needed, and still received data access.

Audit every place where accounts can be created. For each one, check what the account can reach by default and whether strong authentication is enforced. Default to no access, then add what is needed.

Lesson 4: Do not dismiss odd accounts

This one hurts. Staff noticed strange accounts in June, reviewed them, and decided they were harmless. That conclusion was wrong. The review looked at what the accounts were meant to do, not what they could actually do.

When something looks off, test the real permissions. Log in as that account type in a safe environment and try to read the data. Assumptions are not evidence, and attackers rely on teams trusting their assumptions.

Lesson 5: Archives are liabilities

Why was old customer identity data still sitting in a reachable business system? Archived data is easy to forget and hard to defend. Every passport scan you keep is something you must protect forever.

Set retention limits. Move old records to locked-down storage, or delete them when the legal need ends. Regulations like GDPR already push in this direction, and data you do not hold cannot be stolen. For a plain-language overview of the principle, see the NIST Cybersecurity Framework.

What your team can do this week

You do not need a big budget to act on this story. Start with four small jobs. First, list every system that holds customer documents or identity data. Second, check who and what can reach each one from the internet. Third, review account creation paths for missing MFA. Fourth, set a retention rule and put a date on enforcing it.

Then look at your change process. If a network or hosting change can ship without a security check, add one. Even a short template works: what changed, who can reach it, what data sits behind it.

Finally, practice your response. DigiCert took months to connect the dots between odd accounts and real data access. Faster log review and clearer escalation rules shorten that gap. Run a tabletop exercise with the question: what do we do if we find unknown accounts on an internal system?

Key Takeaways

• Migrations create exposure: Review network reachability every time a system moves.
• Do not rely on the perimeter: Internal tools need their own authorization checks.
• Close MFA gaps: Any account creation path must enforce strong authentication and least privilege.
• Verify, do not assume: Test what suspicious accounts can really access.
• Shrink your archive: Retention limits reduce the damage of any future breach.

How TecniForge Can Help

At TecniForge, we help businesses navigate these technology shifts. Whether you need custom software development, AI integration, or cloud migration, our team builds scalable solutions. Talk to our experts.

When did your team last check what an old internal system can actually be reached by?