Most GRC programs address migration risk by adding a security review gate to the change process. While this is a good start, it's not enough, as the DigiCert incident demonstrates.
The Conventional Wisdom
The common belief is that before a system moves to a new network zone, a review of the resulting attack surface is necessary. If done, potential exposures are caught. If not, breaches occur.
DigiCert's root cause analysis supports this view. The company moved an internal archive from behind a VPN to a publicly accessible network zone in February 2025. They changed the system's accessibility without a security review of the attack surface. The exposure lasted over a year, detected in June 2026 and fixed the following month.
Mandate the review, close the gap. That's the story most programs will take away.
Why It's Incomplete
A review gate is a point-in-time control that relies on recognizing a change as security-relevant. This is the weak link. Moving a system between network zones often gets classified as routine infrastructure work.
The real issue wasn't just the network move. A latent account registration feature was also exposed. The system, built for information storage, not account creation, didn't treat this feature as part of the external attack surface. Accounts created through it weren't subject to multifactor authentication, allowing unauthorized access to customer records.
A reviewer asking "is this migration approved?" might miss this feature. Instead, they should ask "what can an anonymous stranger do to this system now?" Most checklists only address the first question.
During detection, DigiCert initially concluded the unauthorized account couldn't access data because it wasn't assigned to any application. This was incorrect. The real attack path was identified days later after a managed security program flagged the flaw. A control that fires once at approval can't compensate for an incident-triage assumption that fails a year later.
The Evidence
Three details from this incident highlight where point-in-time review falls short:
- The failure was inherited, not introduced. The registration feature existed before the migration. Only a review of what the system exposes, not just its location, would reveal it.
- Authentication assumptions were tied to the old network. Behind a VPN, the lack of multifactor authentication on self-registered accounts was low risk. Once the boundary moved, this assumption silently expired.
- Monitoring didn't cover the new exposure. After remediation, DigiCert added a security information and event management alert for blocked access attempts. This gap existed because monitoring was designed for the old location.
This aligns with established guidance. ISO/IEC 27001 expects change management and risk reassessment. ISO/IEC 27002 addresses network segregation and secure configuration as ongoing controls. NIST Cybersecurity Framework (CSF) 2.0 emphasizes continuous detection, and Zero Trust Architecture exists because network location is a poor proxy for trust.
What to Do Instead
Treat network location as a control you're retiring, not relocating. Specifically:
- Reclassify zone changes as security changes by default. Any move across a trust boundary should trigger a threat-model refresh.
- Inventory exposed functionality, not just hosts. Before cutover, list every reachable endpoint and feature. Consider what an unauthenticated user can do, including forgotten features.
- Re-derive authentication requirements. Identify controls that relied on network position and decide what replaces them. Multifactor authentication should cover all account types, or disable self-registration.
- Verify after migration, not just before. Conduct external attack surface scanning against the new configuration within the cutover window, and compare results to the approved design.
- Rebuild monitoring for the new exposure. Alert on registration events, blocked access attempts, and anomalous reads from archives holding identity documents.
- Challenge your triage assumptions. If an unauthorized account is found, treat "it can't reach data" as a hypothesis to disprove. Escalate until the access path is tested.
- Apply Data Minimisation to archives. Identity documents in a read-accessible archive for years amplify exposure. Under the General Data Protection Regulation, retaining verification documents longer than needed is a risk.
When the Conventional Wisdom Is Right
Don't discard the review gate. The failure here was that no review happened at all, and a competent one would likely have caught the exposure. Pre-migration review remains your most cost-effective control, and for organizations without a gate, it's the first step.
The issue is sufficiency. A gate catches what it's designed to look for at the moment it runs. Your program also needs post-change verification, assumption-tracking for controls tied to network position, and monitoring that adapts with the system. Build the gate, then assume it will eventually miss something, and ensure there's a backup when it does.
