The Challenge
Server migrations are routine. No one expects a major change to lead to a data breach, yet in February 2025, a migration at DigiCert mistakenly exposed an internal business system to the internet. Previously, this system was only accessible via VPN.
The exposure went unnoticed for months. DigiCert discovered unauthorized accounts on the system in June 2026. By October 19, it was confirmed that an unauthorized account accessed customer information between June 27 and July 2, 2026. The exposed data included names, business email addresses, phone numbers, and business addresses. For some, identity documents like driver's licenses and passports were also exposed.
For Third-Party Governance teams, the lesson isn't just about DigiCert's error. It's about how a vendor's change management gap can lead to your data exposure, and how the vendor's response can delay crucial answers.
The Environment and Constraints
Two factors made this incident possible.
A trust boundary changed silently. The system's security relied on its network placement. VPN-only access was the control. When the migration moved the system, this control disappeared without deliberate action.
A dormant feature became live. The system included a self-registration feature for other applications, allowing external users to create accounts. Behind a VPN, this was convenient. On the internet, it was a vulnerability. Although these accounts weren't linked to any application, an authorization flaw allowed them to read archived customer information in read-only mode.
This incident combined a failed network control, an unintended external-facing registration feature, and a flawed authorization layer. Each issue alone might have been manageable, but together they weren't.
The Approach Taken
DigiCert's response unfolded in stages, and the sequence is important.
- Initial detection (June 2026): Unauthorized accounts were found. DigiCert initially believed they couldn't access customer information since they weren't linked to an application.
- External report: A report through DigiCert's security research program warned that external users could create accounts.
- Remediation: Fixes were deployed to restrict system access and address the authorization flaw. At this point, DigiCert didn't realize archived data had been accessed.
- Confirmation (October 19): Further investigation confirmed that an unauthorized account had accessed customer information.
- Hardening: Access to the affected system was restricted, self-registration was disabled, and access controls were added.
- Notification: Affected customers began receiving breach notices while a review of identification documents continued.
DigiCert's incident report states the core error: "The incident was initially handled as an account-creation issue rather than a data-access event."
Results and Outcomes
The outcomes are mixed, and a Third-Party Risk Management (TPRM) reader should consider both sides.
What held: The unauthorized account had read-only access. It couldn't modify records or issue certificates. DigiCert states that its certificate authority services, CertCentral, and DigiCert ONE were not compromised. Customer login credentials and issued certificates remain secure. For a certificate authority, maintaining trust infrastructure is crucial.
What didn't: Customer PII and some identity documents were exposed. The gap between the access window and confirmation is significant. DigiCert hasn't disclosed how many people were affected, and its review of identification documents was ongoing when notifications were sent. One affected customer, cloud architect Fabian Bader, publicly shared his notification, highlighting customer reactions.
What They Would Do Differently
DigiCert's report points to key lessons. Based on the sequence above, these changes would have mattered most.
Treat unauthorized accounts as data-access issues from the start. The fix addressed account creation, but the focus should have been on whether any account accessed data. Reviewing logs for data access, not just account provisioning, would have sped up confirmation.
Run a post-migration exposure check. Verify that systems haven't become exposed after a migration. Compare pre- and post-migration access models before closing the change.
Inventory dormant features on internal systems. Self-registration was harmless behind a VPN. Any feature assuming a trusted network should be flagged and disabled before facing outward.
Don't assume the authorization layer is correct by default. Accounts not assigned to an application still accessed data. Deny-by-default for unassigned identities is a design choice, not a given.
Takeaways for Your Team
You can't prevent a vendor's migration error, but you can limit your exposure and speed up your response.
- Ask about change management in due diligence. Request evidence of how the vendor validates access controls after infrastructure changes, especially for systems with archived data. Include this in your Pre-Contractual Assessment and revisit it annually.
- Classify archived data holdings. Vendors often protect live systems well but neglect archives. Your Criticality Classification should include historical data, like identity documents.
- Tighten notification timeline language. A long gap between exposure and confirmation shows why contracts should tie notification to suspected unauthorized access, not just confirmed data compromise. Align your Vendor Breach Management expectations with your regulatory timelines.
- Pressure-test continuous monitoring of active arrangements. External signals can reveal issues before the vendor confirms them. An external report highlighted the account-creation issue. Ensure your monitoring and Incident Escalation paths can act on partial information.
- Test the vendor's incident framing. Ask how a vendor classifies and reclassifies incidents as facts change. A narrow label leads to narrow investigations.
- Minimize what you send. If a vendor retains identity documents indefinitely, ask about retention schedules and deletion. Data that doesn't exist can't be exposed.
The DigiCert case reinforces a simple standard from frameworks like ISO 27036 and SR 23-4: oversight of a vendor includes oversight of how it changes. Controls that exist on paper but disappear during a migration aren't controls, and your assessment process should identify this.
