DigiCert data breach exposed archived identity documents

An account with no application assigned could read DigiCert's archived customer data — including identity documents in some cases. The DigiCert data breach hit an internal business system exposed during a server migration, not the certificate platforms, the company says. I'd say the practical response is to check exposure notices and review registration and authorization controls, not replace active certificates.

For customers who submitted identity-verification documents, the concern extends beyond business contact details. BleepingComputer reports that DigiCert has begun notifying affected customers, with some records containing documents such as passports or driving licences. DigiCert says its review of identification documents was still under way when it sent the notification, so I'd advise recipients to distinguish confirmed exposure from information still being assessed.

How the migration opened the archive

The entry point was a network change. According to DigiCert's full incident report on Mozilla Bugzilla, an internal business system moved from a virtual private network (VPN)-restricted segment to another availability zone on February 4, 2025. That migration inadvertently made the system externally accessible. DigiCert says the migration was treated as an infrastructure change rather than a security change, so it did not receive the more detailed security review and sign-off.

The exposed system used an account manager with an optional self-registration flow intended for other implementations. That flow became available on the business system even though the system was not intended to use it. Accounts created through this route had no application assigned and did not receive the multi-factor authentication (MFA) that DigiCert otherwise required.

In my view, the decisive failure was authorization. These unassigned accounts received read-only access to archived information rather than being denied access. DigiCert's initial review incorrectly concluded that the absence of an assigned application meant the account could not reach customer data. The account's apparent lack of entitlement did not match what the system actually allowed.

The July fix came before confirmation of data access

DigiCert blocked the authorization path before it established that customer information had already been accessed. The company says it restricted access to the system, disabled self-registration, and added access controls. Its July authorization change validated the account-manager token and returned HTTP 401 for accounts without an assigned application.

The DigiCert data breach therefore has different containment and confirmation dates. The company's own description of its initial handling is direct:

“The incident was initially handled as an account-creation issue rather than a data-access event.”

— DigiCert's full incident report

My concern is that initial stopping point: the review inferred what the account could do from its assignment state instead of establishing what it had actually accessed. DigiCert says retained logs and audit tables later allowed investigators to reconstruct the access list, access window, and account activity. Those records also supported its finding that the account performed no write actions.

The DigiCert data breach scope still lacks a customer total

DigiCert describes the affected information as a small proportion of its archived data. Most of it consisted of customer representatives' names, business email addresses, phone numbers, and business addresses. The company has not supplied a numerical definition of that proportion in its full incident report.

A small minority of customer accounts also included additional personal information in customer-provided documents. DigiCert names driving licences, passports, utility bills, and other documents containing a name and address. That does not mean every affected person lost every document type. The notification described by BleepingComputer says DigiCert was reviewing identification documents to determine whose documents were involved and would notify those people after completing that review.

The company says its certificate systems were not compromised. DigiCert's certificate authority (CA) services, CertCentral, and DigiCert ONE were unaffected. Customer login credentials and issued certificates remain secure, valid, and trusted, according to DigiCert. The unauthorized account could not write records, act as a validation approver, or issue certificates. DigiCert says its review of CA and validation logs found no associated validation, issuance, or revocation activity.

In my view, the unresolved customer total matters when interpreting the company's description of the incident as limited. BleepingComputer says it asked DigiCert how many people were affected, but its report supplies no answer. I see the supported distinction as between a bounded archive-access incident and unaffected certificate operations — not between a known small number of victims and everyone else.

Check DigiCert notices without replacing active certificates

DigiCert says active certificates need no action; customers should check which personal records were exposed. DigiCert explicitly says customers need take no action regarding active certificates or continued use of its services. I'd start with the notification and the people who supplied verification documents, rather than a certificate-replacement project.

1. Identify what the notice actually confirms. Separate business contact information from identification documents that are confirmed as involved or still under review. Record the categories DigiCert names for your organisation rather than assuming that every item in its general description was present in your records.
2. Bring the notice to the people responsible for your organisation's security and privacy response. As a recommended internal hand-off, include the affected representative and the document categories identified. This keeps the response tied to the archived personal information rather than treating it solely as a certificate-administration issue.
3. Seek document-specific clarification where the notification remains conditional. DigiCert said it would notify people whose identification documents were affected after its review. Until that clarification arrives, distinguish an unresolved question about a submitted document from a confirmed disclosure of that document.
4. Keep certificate work separate from the privacy response. DigiCert's stated position is that active certificates need no action. Its report does not call for customers to replace certificates or change their use of CertCentral or DigiCert ONE because of this incident.

Audit registration and authorization after internal migrations

In my view, DigiCert's root-cause analysis points to checks that belong together: network exposure, registration behaviour, application assignment, and actual data access. I'd use the following sequence when reviewing a comparable internal archive, because it follows the failure path DigiCert documented rather than stopping at the network boundary.

1. Review the security effect of the migration. Establish whether a system previously reachable only through a VPN has become externally accessible. DigiCert says its network change did not trigger the detailed security review it should have received. Make the review cover the resulting attack surface, including account-registration functionality, rather than only whether the migrated application still works.
2. Inspect registration features inherited from shared account-management software. DigiCert's business system exposed an optional flow intended for other uses. Check whether a comparable system offers self-registration at all, whether it is intended, and what happens to an account created through it. Include the MFA requirement in that review instead of assuming every registration path applies the staff sign-in controls.
3. Test access with an account that has no application assigned. The expected result should follow your authorization policy, not an assumption about the account's status. DigiCert's fix rejected these accounts with HTTP 401. For a comparable archive, explicitly test whether such an account can retrieve records; testing only whether it can modify them would miss the read-only access involved here.
4. Review account and request monitoring alongside the access controls. DigiCert identified insufficient alerting for new accounts created through the exposed endpoint and for request volume at internal endpoints. It later added application-access and request-volume alerts. Use those documented gaps to decide which account-creation and data-access events your own system needs to surface.
5. Investigate data access when unexpected account creation is discovered. Preserve and examine the logs and audit records needed to connect an account to its activity. DigiCert's retained records allowed that reconstruction later. The investigation should establish which records were accessed, when access occurred, and whether there were write actions, rather than closing with an account-assignment check.

I'd note these are review and test objectives, not a configuration recipe: DigiCert's report describes the failure and the authorization behaviour of its fix, but does not publish deployable code. Apply the checks to the system you operate without assuming its account manager or authorization implementation matches DigiCert's.

I see the useful lesson from the DigiCert data breach as being that an internal location was carrying too much of the security assumption. Once the network boundary changed, an unintended registration flow and permissive read access became reachable together. DigiCert's report explicitly says business-system authorization must not depend on network position.

Migration sign-off should demonstrate that unassigned accounts cannot retrieve records.