DigiCert’s Incident Report Dates Every Confirmed Read of Its Customer Archive After the Day It Verified Outsiders Could Create Accounts, and It First Suspected a Data Read 102 Days After the Fix

DigiCert, a publicly trusted certificate authority, has told Mozilla’s CA program in a public incident report that an internal system it uses to archive customer information was left with a self-registration feature, which skipped multi-factor authentication, reachable from the internet. The exposure ran from a server migration on February 4, 2025 until a fix on July 2, 2026. That is 513 days (our arithmetic), nearly 17 months where The Register’s headline says 16. One self-registered account read a subset of the archive between June 27 and July 2, 2026. DigiCert says the subset held names, business email addresses, phone numbers and business addresses and, for a small minority of customer accounts, a customer-provided document such as a driver’s license, passport or utility bill. It has begun notifying customers and has not said how many people are affected.

The report’s own dates carry the sharper finding. Every confirmed read falls after DigiCert verified, on June 24, that accounts could be created through external access, and after a firewall rule had blocked new registrations on June 18. DigiCert says it first suspected possible unauthorized access to the archived data on October 12, which is 102 days after the fix shipped, and confirmed it on October 19.

DigiCert says its certificate authority systems, CertCentral and DigiCert ONE were unaffected, that customer login credentials and issued certificates remain secure, and that customers need take no action on active certificates. Its report says the account could not write records, approve validations or issue certificates. We could not test any of that independently; it rests on DigiCert’s own logs and audit tables.

How the door opened

On February 4, 2025 DigiCert moved the internal system from a VPN-restricted network segment to a different availability zone. The report says the move “inadvertently allowed this internal business system to be accessible externally.” The system runs its own instance of the same account manager that DigiCert uses for customer-facing products, and that product includes a self-service registration flow meant for other uses. Accounts created through it, the report says, “were not subject to the multi-factor authentication (MFA) that DigiCert otherwise requires, and were assigned read-only mode by default.” It adds that “these unassigned accounts had access to archived data on the business system.”

The root-cause section explains why MFA never applied: “MFA is only enabled if the account is assigned to an application that requires MFA.” A new account with no application assigned skipped MFA and, in the report’s third contributing factor, could still have read-only access to data. DigiCert’s own lesson list is blunt: “Authorization for a business system must not be delegated to its network position.”

The June review that cleared the accounts

The timeline says an internal team observed non-DigiCert accounts on the system on June 18, 2026. Because the accounts were not assigned to any application, “the reviewer concludes they did not have data access.” The same day the system was placed behind a web application firewall that blocked new account creation through external access. Three days later DigiCert received a report from its managed security program that accounts could be created through external access, and on June 24 it verified that ability.

The data-access window then opens on June 27, “shown by subsequent investigation,” and closes on July 2, when an authorization patch reached production. In between, engineering identified the root cause on June 30 and had a patch ready on July 1. DigiCert concedes that “initial reviews concluded incorrectly, from the absence of an assigned application, that the account had no data access,” and lists as a miss that “the incident was initially handled as an account-creation issue rather than a data-access event.”

Two details follow from those dates, and the report states neither. First, because the firewall rule of June 18 stopped new registrations through that path, the account that read the archive was most likely already on the system during the June 18 review (our inference; the report does not say when it was created). Second, the report does not say whether anyone tested what an unassigned account could read, or looked at access logs, in June. The review’s stated reasoning is the missing application assignment.

The timeline, with the gaps

Some endpoints stayed reachable from the internet after July 9 on purpose: the report calls them “approved externally-accessible endpoints,” and they moved to private-IP load balancers only on October 24, 627 days after the migration.

What the report does not say

• How many people. The report says the incident “affected only a small proportion of archived data” and that “DigiCert can make summary statistics available to Root Program representatives on request.” An outside commenter asked on November 5 for “numbers on the data set exposed.” The Register and SecurityWeek say DigiCert has not disclosed a count, and BleepingComputer says it has asked. Since that question, DigiCert’s only posts in the bug are two action-item completions.
• What prompted the October 12 investigation. The timeline row says only that DigiCert “first suspects possible unauthorized access to the archived data, begins additional investigation.” A second commenter asked on November 6 what “led DigiCert to suspect that a data breach had occurred, and what specific indicators or findings prompted the investigation.” As of this writing it has no answer in the bug.
• Who created and used the account. SecurityWeek writes that “attackers abused a self-registration feature”; the report says “unauthorized access” and “an unassigned account,” and does not say who created the account, how many accounts were self-registered, or how many records this one opened.
• What the archive is for. The preliminary report, filed October 20, described a system that “stores information customer representatives provide to us to validate their identity.” The full report describes an archive of “business contact information and, in some cases, additional personal information of customer representatives.” The first commenter asked whether this is subscriber verification information, and the second asked how the system integrates with certificate validation. Neither has an answer in the bug.
• Whether a given person’s document was in the accessed subset. DigiCert’s notice, as quoted by The Register, says “we are completing a review of identification documents to determine the specific individuals involved.” One customer, writing on X, described the leak as covering “only my full PII data and potentially any verification documents I submitted for my certificate.”

Why a certificate authority holds this archive

CAs keep records of how they verified who asked for a certificate. The TLS Baseline Requirements (version 2.3.1) set a floor in section 5.5.2: the CA must keep archived documentation on verification, issuance and revocation for “at least two (2) years” after the later of the last time the records were relied on and the expiry of the certificates that relied on them. A note adds that the CA “MAY choose a greater value as more appropriate in order to be able to investigate possible security or other types of incidents.” DigiCert’s report does not say which retention rule governs this archive, how old its oldest records are, or how long it keeps identity documents.

DigiCert lists two other recent root-program incidents as related, because they “dealt with privacy and management of archive data.” In bug 2085547, opened October 24, D-Trust reported that an external registration authority lost records covering subscriber identity validation data, with a seven-year retention period stipulated in the dedicated certification practice statement for that registration authority. In bug 2086949, opened October 29, TWCA reported “indicators of unauthorized access to our Registration Authority (RA) server.” We covered a different CA incident, eMudhra’s key compromise, on October 22.

Where it sits under the incident-reporting rules

Mozilla’s Root Store Policy (section 2.4) requires CA operators to follow the CCADB Incident Reporting Guidelines. Those guidelines expect a preliminary or full report “within 72 hours of a CA Owner becoming aware of an incident,” a full report “within 14 days of the incident’s initial disclosure,” and a response to comments and questions “within 7 days.” On DigiCert’s dates (reportable event determined October 19, bug opened October 21 UTC, full report November 1) the filings fit those windows. The clock runs from when the CA becomes aware of an incident, though, and the report itself says the first handling treated this as an account-creation issue, so October 19 is DigiCert’s account of when it knew. Both open questions are still inside the seven-day response window, which runs to November 12 and 13.

What customers and engineers can do

If you are a DigiCert customer

These are our suggestions, not DigiCert’s guidance. Read the notice for the data categories it lists, and keep in mind that DigiCert says it will notify people individually once its review of identification documents is done. Expect targeted phishing: the exposed fields (names, business emails, phone numbers and addresses of people who buy certificates) are what an impersonator of DigiCert validation or renewal staff would need, so reach your DigiCert account by typing its address rather than following a message. If you uploaded a passport or driver’s license, treat it as any identity-document exposure and use the monitoring, fraud-alert or credit-freeze options your country offers. For certificates, DigiCert says no action is needed, and the basis for that is its own logs.

If you run an internal system

The report’s three contributing factors translate into three checks. Treat any change to who can reach an internal system as a security change: DigiCert says its migration was “treated as an infrastructure change rather than a security change.” Create a throwaway account with no role in staging and list what it can read; the answer should be nothing. And after you close a hole, query the access logs for the whole exposure window, because the evidence DigiCert used in October was retained logs and audit tables, and its new request-volume alert, per the report, “would have triggered” on July 1.

Sources and method

We read the full Mozilla Bugzilla bug 2084460 through its REST API (preliminary report, full report, bug history and all seven comments, last change 18:52 UTC on November 6), the related bugs 2085547 and 2086949, the CCADB incident-reporting guidelines, Mozilla’s Root Store Policy and the TLS Baseline Requirements 2.3.1 in the CA/Browser Forum repository. The day counts are our arithmetic from the report’s dates. We did not contact DigiCert, test its systems or see the archive, and we know the customer notice only through the passages the outlets and one customer’s post published.

• Mozilla Bugzilla bug 2084460, “DigiCert: Unauthorized access to business system” (preliminary report, full report, first question, second question)
• Bug 2085547, D-Trust and bug 2086949, TWCA
• CCADB incident reporting guidelines and Mozilla Root Store Policy
• TLS Baseline Requirements, section 5.5.2
• The Register, SecurityWeek and BleepingComputer on the disclosure
• A customer’s post on X about the notice they received