DigiCert says its Certificate Authority (CA) services, CertCentral, and DigiCert ONE were unaffected by unauthorized access to an internal archive business system. Customer login credentials and DigiCert-issued certificates remain secure, and customers do not need to reissue active certificates or stop using DigiCert services because of this incident. Those boundaries should lead any internal response, not be buried beneath a breach headline. [1]
The incident nevertheless warrants a focused privacy and supplier-risk review. DigiCert confirmed access to a small proportion of archived customer data: predominantly business contact information, with additional personal information in customer-provided documents for a small minority of customer accounts. The unauthorized access was read-only and could not write records, approve validations, or issue certificates. [1]
Rescana assessment: Medium severity; High reach. These are editorial incident assessments, not a vendor CVSS score. High reach reflects DigiCert's role as a major public certificate authority, not a claim that all customers were affected. Medium severity reflects the exposure of personal information, including some identity documents, alongside the explicit separation from certificate operations and customer login credentials. No CVE or exploitation score is assigned here.
For customer security, privacy, and procurement teams, the prepare-now task is to establish whether their representatives' archived records were involved, determine the sensitivity of any documents, and obtain evidence of the archive's access-control remediation. Emergency certificate replacement is not supported by DigiCert's report.
Technical Information
An internal archive became externally accessible
DigiCert's full incident report describes an internal business system used to archive information supplied by customers. On February 4, 2025, an infrastructure migration moved that system from a VPN-restricted segment to an externally accessible availability zone. The migration exposed an account-registration feature intended for other implementations of the account manager. The business system used its own instance, separate from the customer-facing instance. [1]
DigiCert staff signed in with MFA. However, self-registered accounts with no application assignment were not subject to the MFA requirements otherwise enforced through application assignment. The system's authorization model unexpectedly allowed those unassigned accounts to read archived data. This was not a demonstrated compromise of the CA infrastructure or an ability to mint trusted certificates. [1]
DigiCert attributes the incident to three contributing factors: network accessibility changed without the appropriate security review; monitoring and alerting did not adequately cover business-system account activity; and the authorization model did not anticipate self-registration. Its report says authorization must not be delegated to a system's network position. That lesson matters to customers reviewing a supplier's administrative tools as well as its production service. [1]
Exposure and confirmation are different dates
The vendor distinguishes a long period of unintended network accessibility from the much narrower confirmed data-access window. Its reconstructed access window is June 27 through July 2, 2026. It does not say customer data was being accessed throughout the period beginning in February 2025. [1]
Key milestones in DigiCert's report are:
- June 18, 2026: an internal team observed non-DigiCert accounts, initially concluded they lacked data access, and placed the system behind a WAF to block external account creation.
- June 21–24: a managed security program report prompted verification that external account creation was possible.
- July 2: an authorization restriction denied archived-data access to accounts with no application assignment, ending the subsequently confirmed access window.
- October 12: DigiCert first suspected unauthorized access to archived data and began additional investigation.
- October 19: DigiCert confirmed the data-access event and determined it was reportable under browser root-program requirements.
- October 20: DigiCert filed its preliminary incident report. [1]
These are the vendor's calendar dates; the report does not supply times of day for these events. The delay between remediation and recognition of data access is relevant to a supplier review. It is not evidence of a new, ongoing certificate compromise.
What information was involved—and what was not
According to DigiCert, most exposed information consisted of names, business email addresses, phone numbers, and business addresses. A small minority of customer accounts included a customer-provided document, such as a driver's license, passport, utility bill, or another document containing a name and address. The report does not publish an affected-person or affected-customer total. Do not interpret its qualitative scope language as a numeric estimate. [1]
DigiCert states that no certificates were affected, issued, modified, or revoked as a result of the incident. Its review of CA and validation logs found no validation actions, certificate issuance, or revocation activity associated with the account. The report also says the CA systems operate on their own secure network segments. Customer login credentials are explicitly outside the reported compromise. [1]
BleepingComputer separately reports that DigiCert began notifying affected customers and was still reviewing identification documents to determine who was affected. That notification detail is secondary reporting, not an independently inspected customer notice in this advisory. A customer's own notification or direct confirmation from DigiCert should determine their individual response. [2]
Affected Product Versions
Not applicable as a software-version advisory. The affected scope is an internal archive business system, not a published vulnerable release range for CertCentral, DigiCert ONE, or a customer-installed package. DigiCert says those customer-facing services and its CA services were unaffected. [1]
No CVE is identified in the incident report. CISA KEV is a CVE catalog, not an incident registry; no applicable KEV designation is made here. Customers should not infer a patch requirement for their certificate-management software, an exposed customer password, or a need to replace certificates from this archive incident.
The practical scoping question is which customer representatives supplied archived information, and whether their records or documents were accessed. An organization's use of DigiCert alone does not establish that its representatives' data was involved. Keep the status recorded as confirmed affected, confirmed not affected, or awaiting vendor confirmation rather than treating silence as proof either way.
Workaround and Mitigation
Obtain a customer-specific exposure statement
Ask DigiCert to confirm whether your organization's records were accessed, the categories involved, and whether any identity or address-verification document was included. Request the document type and an appropriate description of the exposed fields through an authenticated channel; avoid circulating copies of identity documents in ordinary ticket threads.
Route any confirmed document exposure to the privacy or legal owner for jurisdiction-specific assessment and to the representatives involved. Business contact details can support credible impersonation attempts even when account credentials remain secure. Treat phishing or identity misuse as risks to prepare for, not activity demonstrated by this incident report. Verify unexpected requests to replace certificates, change payment details, or supply new identification through an established channel.
Verify remediation evidence, not just a closed ticket
DigiCert reports that it restricted network access, corrected authorization, disabled self-registration on the business-system instances, moved remaining externally accessible endpoints to private-IP load balancers and internal hostnames, and completed an endpoint-level least-privilege review. It also describes added file-access and request-volume alerts and password resets for users of the affected business system. Those internal resets must not be presented as evidence that customer login credentials were compromised. [1]
The full report lists two November 6 action items: an internal audit confirming no business-system origin server remains externally accessible, and a final review of automated account and permission-change alerting. A later DigiCert update in Comment 4 says the alerting action, Item 13, is complete. As of November 6, 2026, 08:13 Asia/Jerusalem, the report still lists Item 12 as ongoing; do not mark every action complete without a subsequent vendor update. [1]
Useful evidence requests include:
- Confirmation that both WAF-fronted endpoints and origin servers are covered by the external-access review.
- Authorization tests showing that unassigned accounts cannot read archived records, regardless of network location.
- Evidence that unexpected account creation and permission changes trigger monitored alerts with an escalation owner.
- A named owner and mandatory security sign-off for future network-accessibility changes.
- The retention rationale and deletion process for identity documents no longer needed for the customer relationship.
These are recommended customer assurance questions, not claims that DigiCert has failed each control. Keep ordinary certificate lifecycle management running. Do not perform a blanket certificate reissue, emergency CA migration, or customer password reset solely on the facts disclosed here.
Indicators of Compromise
No actionable public IoCs were published in the reviewed sources. DigiCert's report does not provide malicious IP addresses, domains, file hashes, or account identifiers suitable for customer-side matching. This advisory therefore supplies no invented detection rules or attacker attribution. [1]
The vendor's reconstructed access dates are incident context, not proof of compromise in a customer's own environment. Customer teams can preserve relevant notifications and investigate suspicious communications under their normal procedures without treating every message from a certificate supplier as malicious.
Third-Party Risk Management: What to Do With DigiCert Today
Maintain two separate workstreams: privacy exposure for archived representative data, and assurance that the archive's control failures have been corrected. Request a written scope statement, assign an owner for any affected individuals, and track the outstanding origin-access audit to evidence-backed closure. Preserve DigiCert's explicit assurance that certificate operations, customer credentials, and issued certificates were not compromised in the same risk record as the exposure details.
For procurement and security reviewers, the decision is not simply whether a major CA has reported an incident. It is whether your data was involved, whether retained identity documents are proportionate to the business need, and whether the supplier can demonstrate durable authorization and change-control improvements. Reassess on new evidence without turning a bounded archive incident into an unsupported claim about the trust of active certificates.
Need help separating certificate-service assurance from archived identity-data exposure across your suppliers? Our team can help you prioritize the evidence requests and track their answers. Talk to an expert
Sources
- DigiCert: Unauthorized access to business system — Mozilla Bugzilla 2084460, DigiCert full incident report, action table, and subsequent Comment 4. Reviewed November 6, 2026 (Asia/Jerusalem).
- BleepingComputer: DigiCert data breach exposes customer information, identity documents, Lawrence Abrams, November 5, 2026. Secondary reporting; notification details attributed above.
