DigiCert has disclosed that an internal business system was exposed to the internet during a server migration, allowing an unauthorised account to read some archived customer information. The certificate authority says the affected records included business contact details and, for some customers, identity documents. The incident is significant because DigiCert is part of the digital certificate ecosystem, but the available incident account does not say that certificate-signing keys or issued certificates were compromised. That distinction is essential when assessing the scope of the event.
Archived records included customer and identity data
DigiCert’s notification, as reported by BleepingComputer, says the affected archived records could include names, business email addresses, phone numbers and business addresses supplied by customers. Some records also contained identity documents such as driver’s licences, passports or utility bills. The company said it was still reviewing the documents to identify everyone affected and would notify people as that review progressed. The reporting does not provide a final count of affected customers, so it would be premature to describe the incident as affecting all DigiCert customers.
Identity documents can create a longer-lived privacy risk than an ordinary email address because they contain information that may be reused in impersonation attempts or fraudulent account-verification requests. Customers who receive a notification should establish exactly which fields and documents were involved, whether the documents were viewed or downloaded, and whether the company recommends any additional steps. The risk differs between a record containing only business contact details and one containing a passport or other identity evidence.
A server migration exposed an internal system
According to the incident report referenced in Mozilla’s Bugzilla platform, a February 2025 server migration mistakenly made an internal business system reachable from the internet even though it had previously been accessible only through a VPN. The system included a self-registration function intended for other applications. External users could create accounts, and an authorisation flaw then allowed those accounts to access archived customer information in read-only mode.
The timeline shows a common weakness in security incident handling: an event can be classified too narrowly at first. If a team sees unexpected account creation but assumes those accounts have no useful permissions, it may close the issue without checking whether another application or authorisation path exposes data. The later discovery that an account had read-only access shows why identity creation, permission assignment and data access must be investigated as connected events.
DigiCert says the unauthorised account could not modify records, approve certificate validations or issue certificates. It also says its certificate authority services, CertCentral and DigiCert ONE platforms were not compromised, and that customer login credentials and issued certificates remain secure. These statements narrow the reported impact, but customers should distinguish the company’s current assessment from independent verification. The key question for certificate customers is whether their certificate issuance, validation and account-management workflows were affected, not simply whether some archived personal information was exposed.
Server migrations should include an explicit review of network exposure, identity flows and authorisation rules. Systems that were previously VPN-only should not become internet-accessible simply because a new environment has different default routing or firewall rules. A migration checklist should verify the intended exposure of every service, test unauthenticated access from outside the corporate network and confirm that self-registration is disabled where it is not required.
Customers should also review whether the exposed documents were used for certificate identity checks or other business verification. That does not mean a certificate was issued fraudulently; it identifies a sensible question for affected organisations to raise with DigiCert.
The timeline is important because the initial exposure and the later confirmation of data access were separate events. According to the incident reporting, DigiCert discovered unauthorised accounts in June but confirmed access to archived customer information only after a further investigation in October. That sequence shows why account creation, access permissions and data-access telemetry need to be investigated together, even when an account appears to have no assigned application role.