A Server Migration Quietly Exposed Archived Customer IDs

The Challenge

In February 2025, a server migration at DigiCert mistakenly exposed an internal business system to the internet. Previously, the system was accessible only via VPN. After the migration, it became publicly reachable.

The system included a self-registration feature intended for internal use, allowing external users to create accounts. These accounts weren't linked to any application, but an authorization flaw allowed them to access archived customer data. This data included names, business email addresses, phone numbers, and business addresses. For some customers, it also included identity documents like driver's licenses, passports, and utility bills.

This incident illustrates how a migration can remove an implicit security control. The VPN was the control, and when it was removed, nothing else was in place to prevent unauthorized access.

The Environment and Constraints

Three conditions led to this failure, and your environment might share them.

Network Perimeter as Access Control: The system relied on VPN-only access. The self-registration feature and authorization logic weren't secured against anonymous internet users because, initially, they couldn't reach them. When network assumptions change, controls based on a trusted network can fail silently.

Incomplete Authorization: Accounts without application assignments could still access archived data. This violates the principle of Least Privilege: a newly self-registered account should have no entitlements. A solid Role-Based Access Control (RBAC) model denies access by default, so an account with no role sees nothing.

Accessible Archived Data: The exposed records were archives of customer information, including identity documents. Data kept for verification or recordkeeping was vulnerable to an unauthenticated self-registration flow.

The Approach Taken

DigiCert discovered unauthorized accounts on the exposed system in June 2026. Initially, they believed these accounts couldn't access customer information because they weren't linked to any application.

A report from the company's managed security research program later warned that external users could create accounts on the system. DigiCert then deployed security fixes to restrict system access and address the authorization flaw. At that time, they didn't realize archived data had been accessed.

Further investigation confirmed on October 19 that an unauthorized account accessed customer information between June 27 and July 2, 2026. The company's report highlights the delay's root cause: "The incident was initially handled as an account-creation issue rather than a data-access event."

This statement is critical. The initial response focused on the symptom (rogue accounts) rather than the key question for a regulated data environment: what could those accounts access, and what did they access? The assumption that unassigned accounts were harmless wasn't tested against access logs.

Results and Metrics

The reported outcome:

Exposed data was limited to a small portion of archived customer data: names, business email addresses, phone numbers, business addresses, and, where provided, identification documents.
Unauthorized access occurred between June 27 and July 2, 2026.
The unauthorized account had read-only access. It couldn't modify records, approve certificate validations, or issue certificates.
DigiCert's certificate authority services, CertCentral, and DigiCert ONE were not compromised. Customer login credentials and issued certificates remain secure.
Remediation included restricting access to the affected system, disabling self-registration, and adding access controls.
Notifications were sent to affected customers, and DigiCert stated it was still reviewing identification documents to determine who else was affected.

The number of affected individuals hasn't been published. The delay between the access event and confirmation of data access is notable: confirmation came on October 19, long after the June 27 to July 2 access window.

What They Would Do Differently

DigiCert's account suggests two corrections, and the pattern implies a third.

Treat the First Fix as Incomplete Until Log Review is Done: Closing the hole is containment, not scoping. The fix was deployed without recognizing that archived data had already been accessed. Your incident process should require access-log analysis for any unauthorized account on a system holding sensitive data before the incident is classified or downgraded.

Classify by Data-Access Potential, Not by Event Type: "Account-creation issue" and "data-access event" led to different investigative depths. A classification step asking "what data sat behind this system?" would have escalated the case in June.

Test the Migration, Not Just the Application: A migration changes exposure. A pre-cutover and post-cutover reachability check, along with an external scan confirming that systems intended to be internal are not internet-reachable, would have caught the change a configuration review missed.

Takeaways for Your Team

For Information Security Officers at banks, these lessons align with examination expectations under the FFIEC IT Examination Handbook and the NIST Cybersecurity Framework functions (Identify, Protect, Detect, Respond).

Inventory Implicit Controls Before Any Migration: Document what protects each system today. If it's "behind the VPN," that system needs a second control before moving.
Never Let the VPN Be the Only Layer: Require authentication and authorization on internal systems as if they were internet-facing. Enforce Multi-Factor Authentication (MFA) for administrative and data-bearing access, consistent with NIST SP 800-63B.
Deny by Default for Self-Registration: Any account-creation path should issue accounts with zero entitlements, and entitlements should require an explicit, logged grant.
Reduce What Archives Expose: Identity documents collected for verification are high-value targets. Limit retention to what regulation and business need require, store them apart from general business systems, and restrict read access tightly. Under the General Data Protection Regulation, data minimization and storage limitation apply to exactly this kind of archive.
Run an External Exposure Check After Every Change Window: Compare what is reachable from the internet against your approved list. Treat any difference as an incident until proven otherwise.
Tie Indicator of Compromise (IoC) Triage to Data Scope: An unexpected account on a system is an IoC. Your playbook should force the next question: which data stores can this identity reach, and do the logs show reads?
Make the Researcher Channel a First-Class Detection Source: DigiCert's managed security research program surfaced the exposure from outside. Publish a clear intake path and route reports into the same triage process as internal alerts.
Plan Notification Workflows Early: Reviewing identity documents to find every affected person takes time. Know in advance who owns that review and how you'll notify in stages.