Start with onboarding
MTTD, or mean time to detect, should start at the first sign of trouble. On June 18, 2026, DigiCert staff saw outside accounts on an internal archive and handled them as an account-creation issue. Data was read from June 27 to July 2, and DigiCert confirmed the breach on October 19, 123 days after that first sign.
What happened in the DigiCert breach?
DigiCert, the Utah-based certificate authority, says someone gained unauthorized access to an internal business system that archives information customers provide. It set out the dates in a full incident report on Mozilla's Bugzilla on November 1. News coverage started on November 5 with BleepingComputer.
Most of the data was business contact information: names, business email addresses, phone numbers and business addresses. A small minority of customer accounts also held a document such as a driver's license, passport or utility bill. DigiCert has not said how many people are affected.
The account that read the data "performed no write actions," according to DigiCert, and DigiCert-issued certificates "remain secure, valid, and fully trusted." DigiCert has contacted affected customers and reported the incident to law enforcement. It has not named who read the data.
How did an internal system end up on the internet?
On February 4, 2025, DigiCert moved the system from a network segment that required a VPN to a different availability zone. The move made it reachable from outside.
An account registration feature meant for other uses was also available on the system. Accounts created through it skipped the multi-factor authentication (MFA) that DigiCert otherwise requires. They were read-only by default, but they could still see archived data.
DigiCert's report explains why nobody noticed. The move was "treated as an infrastructure change rather than a security change", so it skipped a detailed security review. Monitoring was not reassessed afterward, and the system had "insufficient alerting for new account creation" through its public endpoint. One of DigiCert's own lessons: "Authorization for a business system must not be delegated to its network position."
Was DigiCert's data exposed for over a year?
The system was exposed for over a year, and the data was read within a six-day window. The Register called it a "16-month security lapse", counted from the February 2025 migration.
DigiCert's timeline puts the reading between June 27 and July 2, 2026, nine days after staff had already seen the outside accounts. We counted two spans from its dates:
- 499 days passed between the migration and the first sighting of outside accounts.
- 123 days passed between that first sighting and the confirmed breach on October 19.
Why did it take until October to confirm the breach?
Because the first sign was filed as the wrong kind of problem. On June 18, DigiCert's team saw accounts that did not belong to DigiCert. They had no application assigned, so "the reviewer concludes they did not have data access." DigiCert put the system behind a web application firewall (WAF), which blocked new accounts from outside.
Three days later, a report arrived through DigiCert's managed security program. The Register describes the source as a security researcher. DigiCert verified the account-creation problem on June 24 and released a fix with an authorization restriction on July 2.
In DigiCert's words, "the incident was initially handled as an account-creation issue rather than a data-access event." After the fix, DigiCert "was unaware" that archived data had been accessed. It first suspected data access on October 12 and confirmed it on October 19, using detailed logs it had kept. It added file-access and request-volume alerts on October 15, and by its own evaluation the request volume on July 1 would have triggered one.
What made DigiCert suspect data access on October 12 is not in the report. A commenter asked on Bugzilla on November 6, and the question was still unanswered on November 9.
When does the MTTD clock start?
MTTD starts at the first sign, and closing that sign as a non-security issue does not reset it. Start DigiCert's clock on October 12 and detection looks like a seven-day job. From the first sign on June 18 it took 123 days, and from the first data access on June 27 it took 114.
Industry studies count from the intrusion. IBM's Cost of a Data Breach Report 2026 puts the average time to identify and contain a breach at 247 days. DigiCert's 114 days from first data access to confirmation sit on that same intrusion clock, though IBM's figure also includes containment. The 499 days measure how long a misconfiguration went unnoticed, which is a different question.
How does MTTD work, step by step in Imperum?
This illustrative example follows Imperum's workflow for SOC management and governance. The screens use synthetic data.
Step 1: Find systems that became reachable from outside
Defensum, Imperum's continuous threat exposure management (CTEM) module in the SecOps Platform, brings inventory from supported endpoint, cloud, identity and security tools into a shared asset record. It checks control health, such as SIEM logging, and shows the evidence behind each risk score.
For the external surface, declare the domains and IP ranges you own and verify ownership. Configured passive sources and, for eligible scope, a registered scanning engine then show what is reachable from outside. Threshold-crossing findings can create or update a Casebook case with their risk context.
Step 2: Give every sign a verdict with evidence
Triage needs an alert to work on, and DigiCert's system had too little alerting on new accounts. So first make account creation on internet-reachable systems raise an alert, then route it to Virtus Triage, Imperum's autonomous alert triage, which runs on alerts routed to it by configured workflows.
Virtus Triage extracts the host, user and indicators, enriches the available evidence and applies policy gates. Where needed, an AI model assesses that context, and the decision is kept with its reasons. Configured actions can close eligible false positives, escalate into a case or send uncertain alerts to the Virtus Triage Queue. Missing or uncertain evidence can lead to human review instead.
An authorized analyst can replace a verdict and enter a reason, and the correction is recorded with a link to the original decision. A conclusion like DigiCert's in June, that an account without an application could not read data, then sits on the record where someone can check it.
Step 3: Measure time to detect from the first sign
When a case opens, link the earlier alerts to it. Casebook brings linked alerts, indicators of compromise, affected entities and analyst notes into the same investigation, so the case holds the first sign as well as the alert that finally raised it.
Platform KPI shows case-based indicators by age, priority, ownership and outcome. Select a reporting window, open supported metric tiles to inspect the cases behind a number, and export the KPI data as CSV or Excel. Write down which event starts your MTTD clock, so this quarter's number and last quarter's measure the same thing.
What should you check this week?
- List the systems moved between network segments or zones this year, and confirm each one had a security review.
- Check every internal system reachable from the internet for sign-up endpoints, MFA and alerts on new accounts.
- Reopen recent alerts on those systems that were closed as non-security issues, and check them for data access.
- If you are a DigiCert customer, look for its notice. DigiCert says no action is needed for active certificates.
Questions about MTTD and the DigiCert breach
What is MTTD?
MTTD, or mean time to detect, is the average time between the first sign of a threat and the moment a team recognizes it as one. It is one of the core SOC metrics. Teams define the start and end events themselves, which is why two MTTD figures are only comparable when those events match.
What is the difference between MTTD and MTTR?
MTTD and MTTR measure two halves of an incident. MTTD runs from the first sign to detection. MTTR, mean time to respond or to resolve, runs from detection to containment or closure. DigiCert shows why both are needed: its fix came 14 days after the first sign, and the data access surfaced 109 days after the fix.
Were DigiCert certificates or keys affected?
DigiCert says its certificate authority services, CertCentral and DigiCert ONE were unaffected, and "no certificates were issued, modified, or revoked as a result of this incident." The account could not write records or issue certificates. DigiCert's report does not mention private keys, and no source says keys were stored in the archive that was accessed.
Which SOC KPI belongs next to MTTD?
Count the signs that were closed as non-security issues and later joined a confirmed incident. That SOC KPI shows when a restarted clock flatters MTTD. Also track how long an exposure exists before its first sign, the span that ran to 499 days at DigiCert, and review both next to MTTR.
