DigiCert customers face a breach risk that replacing a password cannot resolve: exposed identity documents.
DigiCert, one of the world’s most prominent certificate authorities, confirmed an unauthorized party accessed an internal archival business system, exposing customer contact records and personal identification documents. The breach stemmed from a February 2025 infrastructure migration that accidentally exposed an internal system to the open internet for over 16 months.
The company says its certificate authority services, customer login credentials, and issued certificates were unaffected. The exposed customer information could nevertheless support targeted phishing or impersonation attempts.
How an internal archive drifted onto the web
The exposure began on Feb. 4, 2025, when DigiCert moved an internal business archive from a VPN-restricted network segment to a different availability zone, inadvertently making the system externally accessible. Along with the server move, a self-registration feature meant for other applications was inadvertently exposed.
External users could register accounts without the multifactor authentication (MFA) normally required for staff. Although these accounts had no assigned application roles, a permissions flaw granted them default read-only access to archived customer files.
DigiCert noticed non-company accounts on June 18, 2026, and placed the system behind a web application firewall to block new external registrations. Staff initially concluded that accounts without an assigned application could not access data.
A report through its managed security research program followed on June 21. DigiCert deployed an authorization fix on July 2 and confirmed unauthorized access to archived data on Oct. 19.
"The incident was initially handled as an account-creation issue rather than a data-access event," DigiCert acknowledged in its incident filing on Mozilla's Bugzilla.
| Incident milestone | Date recorded | Key operational detail |
|---|---|---|
| Exposure begins | Feb. 4, 2025 | Server moved from VPN segment to external availability zone. |
| Unauthorized access | June 27 – July 2, 2026 | Confirmed window of unauthorized read-only data access. |
| Flaw remediated | July 2, 2026 | Authorization patch deployed to terminate external access. |
| Breach confirmed | Oct. 19, 2026 | Investigation confirms unauthorized data access and determines the incident is reportable. |
Exposed identity documents create lasting risks
Most exposed records consisted of standard business contact data:
- Names
- Corporate email addresses
- Phone numbers
- Physical business addresses
However, a small minority of customer files contained identity verification documents submitted during certificate vetting, such as driver’s licenses, passports, and utility bills.
As cloud architect Fabian Bader posted on X regarding the breach notice: "Thanks @digicert that your data leak was ‘limited’ to only my full PII data and potentially any verification documents I submitted for my certificate.”
DigiCert said the account could not modify records, approve validations, or issue certificates.
What customers and security teams should check
Affected customers should contact DigiCert through a known support channel to establish which records and documents were involved. Organizations should identify the employees or customer representatives concerned and tailor their response to the information exposed.
Be cautious of unexpected requests to resubmit identification, approve certificate changes, or provide account details. Verify those requests independently. These are precautions against potential misuse; the disclosure does not establish that follow-on fraud has occurred.
If government-issued identification was exposed, consult the issuing authority about reporting the incident and whether replacement is appropriate. A replacement may change a document number, but it cannot retrieve existing copies or change every personal detail they contain.
For security teams, the incident also provides specific checks for internal archives:
Area to review | What to verify |
|---|---|
| Application permissions | Accounts without an approved role cannot retrieve records or files. |
| Registration features | Internal systems cannot inherit unnecessary public sign-up functions. |
| Infrastructure changes | Migration reviews include external reachability and application access controls. |
| Monitoring | Unexpected account creation and unusual file-access volumes trigger investigation. |
| Data retention | Identity documents have a documented retention period and deletion process. |
Test permissions with newly created accounts and accounts without assigned roles. Include direct requests to file endpoints: a restricted interface does not demonstrate that the underlying records are protected.
The Zeabur breach and customer-response guidance similarly highlights the need to verify recovery across affected systems. Before closing an archive exposure, establish which accounts could reach which records, preserve relevant logs, and confirm that corrected controls deny unauthorized access.
Read more: Breach response depends on what information was exposed. The mSecure incident explains which accounts and stored credentials customers should prioritize protecting.