One Unreviewed Network Change Exposed Customer IDs for a Year

The Challenge

In February 2025, DigiCert moved an internal system from behind a VPN to a publicly accessible network zone. This system contained an archive of customer business and personal information. No security review of the new attack surface was conducted.

The exposure lasted more than a year. DigiCert detected the intrusion in June 2026 and deployed a fix the following month. The exposed records included names, business email addresses, phone numbers, and business addresses. Some records also contained identity verification documents like driver's licenses, passports, and utility bills.

DigiCert reported that no login credentials or DigiCert-issued certificates were affected, and that its Certificate Authority services, CertCentral and DigiCert ONE, were not impacted.

For your team, the key lesson isn't just the breach itself. It's the change management gap that allowed it to happen.

The Environment and Constraints

The archive was designed for storage, not account creation. This design assumption was critical. When the system moved out from behind the VPN, an account registration feature became accessible to outsiders. Anyone could create an account with access to the internal archive.

Since the system wasn't intended to onboard users, accounts created through that endpoint weren't subject to multifactor authentication. Although these accounts had read-only access, it was enough to exfiltrate customer data.

Two factors combined here. The VPN had been silently acting as an access control, so removing it eliminated a layer that wasn't documented as a dependency. Additionally, a dormant feature, harmless in a closed network, became an entry point once the network boundary changed.

The Approach Taken

DigiCert's root cause analysis identified the core failure: the system's network accessibility changed without a security review of the new attack surface.

Detection and response unfolded in stages:

• Detection. The intrusion was first detected in June 2026.
• Initial Misjudgment. DigiCert initially concluded the unauthorized account couldn't access data because it wasn't assigned to any application. This was incorrect.
• Corrected Analysis. The actual attack path was discovered a few days later, after a managed security program alerted the company to the flaw.
• Remediation. The archive was placed behind a web application firewall, and account creation through external access was blocked.
• Monitoring Improvement. DigiCert added a security information and event management (SIEM) alert for blocked access attempts, closing the monitoring gap.

The company also notified affected customers and partners.

Results and Metrics

The outcome is clear and concerning:

• Time from Change to Detection: February 2025 to June 2026, over a year.
• Time from Detection to Fix: Roughly a month, with the fix deployed the following month.
• Data Affected: A portion of customer records, including identity verification documents in some cases.
• Data Not Affected: Login credentials and DigiCert-issued certificates.

The reputational cost was significant. One security architect noted the leak included his full personally identifiable information and potentially any verification documents he submitted. A security engineer warned that a passport scan plus a utility bill is close to what some help desks accept for an account reset, suggesting these documents could be misused.

This reaction is the real impact metric for a trust-based business. Customers judge you on what they entrusted to you, not just on what wasn't affected.

What They Would Do Differently

DigiCert's root cause analysis points to the first fix: review the attack surface before any network change. Beyond that, several controls are worth examining.

Gate Network Zone Changes Through Change Management. Under ISO/IEC 27001:2022, Annex A control 8.32 (change management) requires changes to information processing facilities and systems to follow change management procedures. Control 8.22 (segregation of networks) addresses how networks are separated. A move from a VPN-protected segment to a public zone is a change to network segregation and should trigger a mandatory security review. For SOC 2, this maps to the change management criteria under CC8.1, which expects authorized, tested, and approved changes.

Treat Network Position as a Control and Document It. If a VPN compensates for weak application-layer authentication, that dependency belongs in your risk assessment. Clause 6.1.2 of ISO/IEC 27001 requires you to identify risks and risk owners. A system whose security depends on its network location carries a risk that changes when the location changes.

Run a Scenario-Based Risk Assessment Before the Move. Ask what an anonymous outsider can reach if every network barrier disappears. This question surfaces dormant features like open registration.

Test Your Incident Triage Assumptions. DigiCert initially concluded the unauthorized account couldn't reach data because it wasn't assigned to an application. This reasoning depended on an assumption about the permission model that proved false. Triage playbooks should require verification of access boundaries, not inference from account metadata.

Monitor the Boundary, Not Just the Interior. The SIEM alert for blocked access attempts was added after the incident. Under control 8.16 (monitoring activities) of ISO/IEC 27001:2022 and the monitoring criteria in SOC 2 (CC7.2), anomalous behavior on externally reachable systems should be an expected alert source from day one. Self-registration events on a system that doesn't support registration are a high-signal detection candidate.

Takeaways for Your Team

1. Make Network Exposure Changes a Defined Trigger for Security Review. Don't rely on engineers to recognize that a "simple migration" is a change in your attack surface. Write the trigger into your change management procedure and evidence it.

2. Inventory What Your Network Boundary Is Protecting. For each internal system, ask which controls exist only because of where the system sits. Those are your migration risks.

3. Account for Identity Documents in Your Data Classification. Passports, driver's licenses, and utility bills carry downstream fraud risk well beyond the compromised organization. Systems that store them warrant stronger controls than the average internal archive, including MFA on every access path.

4. Close the Detection Gap Deliberately. Over a year of exposure means no alert fired on external access to a system that was supposed to be internal. Test whether your SIEM would flag unexpected external traffic to a recently moved system.

5. Expect Auditors to Ask for the Review Record. If your Assurance Engagement samples change tickets, a network zone change with no security review evidence is a finding waiting to happen, and where it exposes customer data, potentially a Major Nonconformity under an ISO/IEC 27001 certification audit.

The lesson isn't that DigiCert lacked controls. It's that a single change bypassed the process that would have found the gap. Your migrations are only as safe as the review gate they're forced through.