Quest Diagnostics Quanum LSM Breach: What the 8-K and HIPAA Rules Say

On 21 October 2026, Quest Diagnostics learned of unauthorized access to Quanum Lab Services Manager (LSM), the portal some clients use to order lab tests and look up results. Quest believes certain patient records were accessed. Practices that use LSM should follow Quest's notice; any team running a PHI portal should check its logs.

This is a young incident. As of 23 October there is no named attacker, no stated cause, no count of affected patients and no list of data fields. Quest has said it is not related to the PHP vulnerabilities that dominated the same week. What does exist is a short SEC filing, a company FAQ with unusually concrete operational detail, and a federal rulebook that now sets the clock for everything that follows.

This post covers what those sources say, how the SEC and HIPAA rules apply, and what teams running clinical portals can do this week. We make no claims about what Quest had in place, how access was gained or who was responsible.

What happened

Quest Diagnostics filed a Form 8-K with the SEC on 22 October 2026 under Item 8.01, Other Events. The filing states that on 21 October the company learned of unauthorized access to its Quanum LSM system, which it describes as a system certain clients use to place test orders and to receive and look up results.

According to the filing, Quest started its incident response procedures to contain the activity, investigate the nature and scope of the incident and put remedial measures in place. It notified federal law enforcement and engaged outside cybersecurity experts. The full scope is still under investigation, but at the time of filing Quest believed that "an unauthorized party accessed certain patient records." The filing also says the incident had not materially disrupted business operations or the company's ability to serve patients.

The same day, Quest posted a notice and FAQ on its website, linked from a banner across its healthcare professional pages. The notice adds operational detail that the 8-K does not carry: Quest paused access to LSM on discovery, paused two other systems as a precaution, kept other ordering channels open, and pointed LSM clients to fallback routes.

Timeline

All times are as published by the cited source. Where a source gives only a date, the table gives only a date.

EDGAR records acceptance times in US Eastern time. As of our last check on 23 October, the notice still carried the 22 October timestamp, and we found no confirmation that LSM had been restored.

What Quest has not said

Quest has not said how access was gained, when it began, how long it lasted, how many patients or practices are affected, which data fields were involved, or whether data was copied out. It has not named a threat actor, and BankInfoSecurity noted it is too early to attribute the incident to any group. We will not guess.

Technical details

This section collects every concrete, defender useful value we could find in primary sources. There are no CVE identifiers, file hashes, domains, IP addresses or other indicators of compromise in any Quest publication or in the reporting we reviewed. That absence is itself a fact worth recording: anyone circulating indicators "from the Quest breach" today is not quoting Quest.

SEC filing metadata

All values below are from the 8-K document and the EDGAR filing index.

The filing has one paragraph of substance; its forward looking statements list the incident's impact first among risks. There are no exhibits beyond the XBRL files.

What Quanum LSM is, per Quest's own pages

Quest's product page describes Quanum Lab Services Manager as a web based way for healthcare professionals to work with Quest online: ordering lab tests, viewing graphed results in real time, ordering supplies and more. The page lists these functions.

The right column is our reading of what each function needs, not Quest's statement of what was accessed.

The product page also describes a companion mobile app, Quest Lab Alert for Physicians, which sends real time notifications of Priority and STAT results and which providers sign in to with their existing Quanum LSM credentials. The page lists iOS 11.3 or later. Quest has not said the app was involved in the incident, and we draw no conclusion; we note it because any team mapping its own exposure should know that a single portal credential can open more than one front door.

System status, per Quest's notice

Continuity paths and contact values from the notice

Prior incidents involving Quest patient data

For context only: the AP report recalls a 2016 exposure affecting about 34,000 people and the 2019 incident at billing vendor American Medical Collection Agency affecting about 11.9 million Quest patients. Nothing links either to this event.

Why a client ordering portal matters

Without speculating about this case, it helps to be clear about the shape of a lab ordering and results portal, because hospitals, imaging networks, pharmacies and insurers run the same thing.

Many identities, one data store. Each client practice has its own users, turnover and habits, but all of them sign in to one application that reaches one back end. The operator cannot see a practice's front desk or shared workstations.

Read access is the sensitive action. In a results portal the most sensitive action is a lookup, which is also what legitimate users do all day. That makes abuse hard to tell apart from normal work.

Separate channels limit the blast radius. Quest's notice draws a line between LSM and the LIS interfaces and EMR integrations that also carry orders, and says the latter were not affected. Whatever the reasons here, the general lesson holds: separated channels let a team pause one without pausing the lab.

None of this says how access to LSM was gained. It explains why the controls below focus on identity, on what a signed in user can reach, and on what happens after sign in.

Who is affected

If you are a patient

Quest says it will notify people as required by law. Until then, treat any unexpected call, email or text that mentions a recent lab test with suspicion, especially one asking for insurance details, payment or a click. Contact Quest or your provider through a number you already have.

If your practice uses Quanum LSM

Use the fallback routes in Quest's notice until LSM is restored. Check any request to reset or "verify" a Quest login against Quest's published numbers before acting, since incidents attract phishing that borrows the real story. Record which staff accounts had LSM access, and read your agreement with Quest; Quest has said that, "as the covered entity," it will make the required notifications.

SEC disclosure: Item 8.01 versus Item 1.05

The choice of 8-K item matters to anyone reading this filing, and it is easy to over interpret.

Since the SEC's 2023 cybersecurity disclosure rules, Form 8-K has had an Item 1.05, Material Cybersecurity Incidents. The SEC's fact sheet on the final rules says registrants must determine materiality without unreasonable delay after discovery and, if an incident is material, file under Item 1.05 generally within four business days of that determination. Disclosure can be delayed if the US Attorney General determines that immediate disclosure would pose a substantial risk to national security or public safety.

In May 2024, the Director of the SEC's Division of Corporation Finance issued a statement that companies disclosing an incident they have not yet found to be material, or have found immaterial, should use a different item, such as Item 8.01. The statement quotes the adopting release: "Item 1.05 is not a voluntary disclosure." It also says that a company filing under Item 8.01 is still required to determine materiality without unreasonable delay, and that if it later finds the incident material it should file an Item 1.05 8-K within four business days of that finding, which may refer back to the earlier filing.

Quest used Item 8.01 and said operations were not materially disrupted. The filing does not say whether a materiality determination has been made, and the choice of item is not a finding that the incident is minor. The staff statement notes that materiality includes qualitative factors such as reputation, customer relationships and possible litigation or regulatory action.

HIPAA breach notification: the clocks that now run

Quest's FAQ says the company is the covered entity for this data and will make notifications as required by applicable law. It also answers yes when asked whether PHI or PII was part of the unauthorized access. That puts the federal Breach Notification Rule, 45 CFR Part 164, Subpart D, at the center of what comes next. Below is what the regulation text says, section by section, using the published text.

Is it a breach? 45 CFR 164.402

A breach is the acquisition, access, use or disclosure of PHI in a way the Privacy Rule does not permit that compromises its security or privacy. An impermissible use or disclosure is presumed to be a breach unless the covered entity or business associate demonstrates "a low probability that the protected health information has been compromised," based on a risk assessment of at least four factors:

1. The nature and extent of the PHI, including the types of identifiers and the likelihood of re-identification.
2. The unauthorized person who used the PHI or to whom it was disclosed.
3. Whether the PHI was actually acquired or viewed.
4. The extent to which the risk to the PHI has been mitigated.

The rule applies to unsecured PHI: PHI not rendered unusable, unreadable or indecipherable to unauthorized persons by a method in HHS guidance. Encryption at rest does not help when an application session can display records in the clear.

Notice to individuals: 45 CFR 164.404

Notice is due "without unreasonable delay and in no case later than 60 calendar days after discovery." The 60 days is an outer limit. Discovery is the first day the breach is known to the covered entity, or would have been known with reasonable diligence, and knowledge of any workforce member or agent other than the person who committed the breach counts.

The notice must be in plain language and include, to the extent possible:

Written notice goes by first class mail to the last known address, or by email if the person agreed to electronic notice. It may be sent in more than one mailing as information becomes available, which matters for an investigation that is still establishing scope.

If contact details are out of date for 10 or more people, substitute notice is required: a conspicuous home page posting for 90 days or notice in major print or broadcast media where they likely live, plus a toll free number active for at least 90 days.

Notice to media: 45 CFR 164.406

A breach involving "more than 500 residents of a State or jurisdiction" requires notice to prominent media outlets serving that state or jurisdiction, on the same 60 day outer limit and with the same content.

Notice to HHS: 45 CFR 164.408

For breaches involving 500 or more people, notice to the Secretary of HHS is due contemporaneously with the individual notice, in the manner HHS specifies on its website. For fewer than 500 people, the entity keeps a log and reports within 60 days after the end of the calendar year in which the breaches were discovered. Reports of 500 or more appear on the HHS OCR breach portal.

Business associates: 45 CFR 164.410

A business associate that discovers a breach must tell the covered entity without unreasonable delay and no later than 60 calendar days after discovery, identifying each affected person as far as possible and passing on whatever the covered entity needs for its own notices. If a vendor sees the problem first, your clock depends on how fast it tells you.

Law enforcement delay: 45 CFR 164.412

If a law enforcement official says a notice would impede a criminal investigation or damage national security, the entity must delay. A written statement sets its own period. An oral statement must be documented, including who made it, and the delay can last no more than 30 days from that statement unless a written one follows. Quest has said it notified federal law enforcement; whether any delay request has been made is not public, and there is no reason to assume one.

Burden of proof: 45 CFR 164.414

The covered entity or business associate carries the burden of showing that all required notices were made, or that an impermissible use or disclosure was not a breach. Write the risk assessment and timeline down as the investigation runs.

The clocks in one table

Counted from a 21 October discovery date, the 60 day outer limit for individual notice falls on 20 December 2026. That is arithmetic on the rule, not a prediction of when Quest will notify. Notices can come well before the limit, can arrive in stages, and can be delayed lawfully under 164.412. State breach laws add their own deadlines and content rules on top of HIPAA, and many states also require notice to their attorney general.

What to do now if you run or rely on a PHI portal

These steps are for any team that operates a client facing portal holding PHI or other sensitive records, or that depends on one. They are not a description of anything Quest did or did not do.

1. Know which portals and integrations hold your patients' data

List every outside portal your staff use that shows patient data, who has accounts, whether accounts are shared, and whether a mobile app uses the same credentials. If you operate a portal, list every client organisation, account type and integration path into the data store. Scan the integration code and images too:

# Inventory and vulnerability scan of the integration service
safeguard scan --dir ./lab-integration
safeguard scan --image registry.example.com/lab-integration:2026.10.20
safeguard scan --sbom ./sbom/lab-integration.cdx.json

# Results are written as JSON under ./output
ls ./output

2. Require phishing resistant sign in for portal accounts that can see results

Passkeys or security keys bound to the portal's origin stop most credential relay and reuse. For workforce accounts behind Microsoft Entra ID, you can see who has registered which methods:

az rest --method get \
  --url "https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails?\$select=userPrincipalName,isMfaRegistered,methodsRegistered" \
  --query "value[?isMfaRegistered==\`false\`].userPrincipalName"

For client accounts in your own portal, measure the same share per client organisation. The weakest client is the floor for everyone.

3. Ask how much one account can reach, then shrink it

A sign in should open a practice's own patients, not the whole data store. Check three boundaries:

1. Tenant boundary. Can a user from one practice query a patient who belongs to another? Test it with two test accounts in staging, including through any search, export and API endpoint, not only the main screens.
2. Time boundary. Does a user need results from ten years ago in an ordering portal, or could older results move to a request based archive?
3. Bulk boundary. Is there a page size, export or report that returns many patients at once? Who needs it?

4. Monitor what happens after sign in

Most portal logging records who signed in. Fewer record which patients each session looked at. You need both. If your application writes a PHI access audit table, a simple hourly count catches bulk lookups. The schema below is an example; adapt the names to yours.

-- PostgreSQL: accounts that viewed an unusual number of distinct patients per hour
SELECT user_id,
       date_trunc('hour', accessed_at) AS hour,
       count(DISTINCT patient_id)      AS patients_viewed
FROM   phi_access_audit
WHERE  accessed_at > now() - interval '30 days'
GROUP  BY 1, 2
HAVING count(DISTINCT patient_id) > 200
ORDER  BY patients_viewed DESC
LIMIT  50;

If your application logs are JSON lines, the same question works with jq:

# Top accounts by result-view requests in one log file
jq -r 'select(.route == "/results/view") | .user_id' app-2026-10-22.log \
  | sort | uniq -c | sort -rn | head -20

# Distinct client IP addresses per account, which flags shared or relayed credentials
jq -r 'select(.event == "login_success") | [.user_id, .client_ip] | @tsv' app-2026-10-22.log \
  | sort -u | cut -f1 | uniq -c | sort -rn | head -20

For plain web server logs in the common combined format:

# Requests per source IP to the results path, highest first
awk '$7 ~ /^\/results\// {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Set thresholds per organisation from your own baseline.

5. Keep enough logs to finish an investigation

The HIPAA burden of proof sits with the entity, and an investigation cannot establish scope from logs that have already rolled off. Check retention on every log that records PHI access. On AWS CloudWatch Logs, for example:

# See current retention for the portal's log groups
aws logs describe-log-groups --log-group-name-prefix /app/portal \
  --query 'logGroups[].{name:logGroupName,days:retentionInDays}'

# Set retention to roughly 13 months
aws logs put-retention-policy --log-group-name /app/portal/access --retention-in-days 400

6. Be ready to pause one channel without stopping the business

Quest's notice shows a contained pause from the outside: one portal paused, other channels open, named fallbacks with phone numbers. Write down which switch pauses your portal, who can flip it, which channels stay open, what clients are told, and how every session ends when you resume. In Microsoft Entra ID, revoking a user's sessions is one call:

az rest --method post \
  --url "https://graph.microsoft.com/v1.0/users/<user-object-id>/revokeSignInSessions"

In Okta, the equivalent is a DELETE to /api/v1/users/<userId>/sessions with an API token. For a portal with its own session store, rotating the session signing key and redeploying ends every outstanding session at once.

7. Patch and rebuild the portal's own stack on a schedule you control

Quest says this incident is not related to the PHP vulnerabilities disclosed the same week. Still, a portal is built from open source components that need a patch and rebuild pipeline measured in days. If your portal runs PHP, check versions now and see our PHP2Shell explainer:

php -v
docker run --rm --entrypoint php registry.example.com/portal-web:current -v

8. Prepare the notification map before you need it

The slowest part of HIPAA notification is mapping accessed records to people and current addresses. Test it: pick a random account and hour, and time how long it takes to list the patients that account viewed, with mailing addresses. If the answer is days, the 60 day limit is closer than it looks.

9. Write the vendor duties into the contract

If you rely on someone else's portal, your contract or business associate agreement should say how fast the operator tells you about suspicious access, what logs you can request, and who notifies patients.

What changed since first reports

• Beyond the 8-K wording, Quest's website FAQ (22 October, 12:00 pm ET) added that Essential Insights and LabHQ were paused as a precaution with no data accessed, that LIS interfaces and EMR integrations were not affected, that eLabs and paper requisitions were available, and that full LSM functionality was expected as soon as 23 October.
• Quest's FAQ and its statement to the AP ruled out a link to the PHP vulnerabilities disclosed that week.
• As of 23 October we found no update giving patient counts, data elements, cause or confirmation of restoration.

Open questions

• How was access to LSM gained, and when did it begin?
• How many patients and how many client practices are affected?
• Which data fields were accessed, and was any data copied out?
• Was the access limited to certain client accounts or practices?
• Was the Quest Lab Alert for Physicians app, which uses LSM credentials, involved in any way?
• Has full LSM service been restored, and with what changes for users?
• Will Quest file a later Item 1.05 8-K, which the SEC staff statement would require if the incident is determined to be material?
• When will the incident appear on the HHS OCR breach portal, and with what count?

Quest's notice page, its SEC filings and the HHS portal will answer these; we will not guess.

What would have helped

Nothing here claims to know what Quest had in place or what happened. These are controls that reduce the damage any unauthorized session can do inside a portal that holds PHI, and that make the response faster.

Practices any team can use

Steps 1 to 9 above are the list: phishing resistant sign in measured per client organisation, tenant, time and bulk boundaries tested in staging, per patient read logging with per organisation alerts, separated channels and a tested pause plan, a fast patch and rebuild pipeline for the portal's own code, a notification map ready before the clock starts, and, for public companies, named owners for voluntary disclosure and the materiality determination.

For a general response template, see our compromised dependency playbook and how SBOMs speed up incident response. For third party risk in another October incident, see the IDCF Cloud ransomware post. For the month's wider picture, see October 2026 security incidents and what would have helped.

Where Safeguard fits

The boundary first. Safeguard does not monitor sign ins to your portal, does not watch which patients a session views, does not run your identity provider and would not have detected or stopped unauthorized access to a web portal. The identity, session, audit and pause controls above live in your application, your identity provider and your operations team. Safeguard would not have prevented this incident, and we do not suggest it would.

Where Safeguard helps is around that core:

• Knowing what the portal is made of. Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, results as JSON under ./output), matches components against vulnerability databases, and shows which projects contain a given component and version. When the next library or runtime advisory lands, you can answer "which of our portals and integration services run it" in minutes.
• Ranking what to fix. Reachability analysis puts vulnerable code paths your application actually calls first, so a portal team's first fixes are the ones that matter.
• Gates before release. Policies and gates are evaluated in the platform and can block, warn, notify or require approval at a checkpoint, so a known vulnerable component does not ship in the next portal release.
• Compliance evidence for HIPAA controls. Safeguard's Compliance and GRC suite (GA) has tabs for Frameworks, Controls, Evidence, Monitoring, Tests, Policies, Risks and Vendors, with connectors that collect evidence from clouds and identity providers. Recording controls such as "quarterly tenant boundary test" with evidence makes drift visible.
• A person on every action. The Safeguard CLI's assistant asks before it edits files or runs commands in its default modes (/permissions offers Ask, Accept edits, Plan, Auto and Strict), and the desktop and phone apps send work to a computer running the CLI where each command is approved or denied. safeguard exec runs the same work in CI.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in two modes: an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases, and it covers seven package ecosystems.

Gold Open Source (gold.safeguard.sh, free, no login) offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) provides hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages; an artifact loses its badge if it regresses.

No vulnerability has been tied to this incident, so neither capability applies to it directly, and we make no claim that either relates to it. They are relevant to the open source components inside any portal you build, where the right habit is pulling patched, signed components from a curated source and rebuilding fast.

Common mistakes

• Reading Item 8.01 as "not serious." The SEC staff statement says 8.01 is the right item when materiality has not yet been determined. It is not a finding of immateriality.
• Waiting for forensics to start the HIPAA clock. The 60 day outer limit runs from discovery, defined as when the breach is known or would have been known with reasonable diligence.
• Logging logins but not lookups. In a results portal the sensitive action is a read. Without per patient access logs, scope is a guess.
• Circulating unofficial indicators. No indicators of compromise have been published for this incident. Blocking addresses from a social media post adds noise, not safety.
• Linking unrelated incidents. Quest has said this is not related to the PHP vulnerabilities of the same week. Treat each incident on its own record.
• Letting phishers borrow the story. Patients and practices will receive messages that cite the breach. Tell them now which channels you will use.

FAQ

What happened in the Quest Diagnostics Quanum LSM breach?

Quest learned on 21 October 2026 of unauthorized access to Quanum LSM, its client ordering and results portal. It paused access, notified federal law enforcement and believes certain patient records were accessed.

What is Quanum Lab Services Manager?

Per Quest's product page, a web platform where healthcare professionals order lab tests, view results with trends, track orders, schedule pickups and order supplies. A companion app uses the same credentials.

How many patients are affected, and what data was involved?

Not known as of 23 October. Quest has said it believes some patient data in LSM was accessed and that PHI or PII was part of the unauthorized access, but it is still determining the specific data and the people affected.

Were other Quest systems affected?

Quest says Essential Insights and LabHQ were paused as a precaution but no data was accessed in them. It says direct LIS interfaces and EMR ordering integrations were not affected and that core operations are running.

Is the breach related to PHP2Shell?

Quest says no. Its FAQ states that, based on its investigation, the incident is not related to a PHP programming language issue, and it told the Associated Press the same thing.

Who was behind it?

No one has been named. Quest has not attributed the incident, and we found no credible claim of responsibility in the reporting we reviewed.

Why did Quest file under Item 8.01 rather than Item 1.05?

Quest has not said. SEC staff guidance from May 2024 says Item 8.01 is appropriate when a company discloses an incident before determining materiality or after finding it immaterial. If a company later determines an incident is material, it must file under Item 1.05 within four business days of that determination.

When will patients be notified?

HIPAA requires notice without unreasonable delay and no later than 60 calendar days after discovery, unless a law enforcement delay under 45 CFR 164.412 applies. From a 21 October discovery, the outer limit is 20 December 2026. Quest says it will notify as required by law; it has not given a date.

What should a practice that uses LSM do today?

Use the fallback routes in Quest's notice (eLabs, fax requisitions, 1-866-MYQUEST for results), verify any credential related request against Quest's published numbers, and record which staff had LSM access in case it is needed later.

Fix it without waiting for upstream

This incident has no published vulnerability or patch. The portal you run, though, is built from open source components, and the next advisory that touches one of them is a race between your rebuild and someone else's scan. The same principles apply.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows this incident, a lab portal or Quest's systems. Each shows a real Safeguard flow that applies to the software and access decisions around a portal that holds PHI.

The first demo is a real CLI session. It installs the CLI, opens the interactive terminal and asks it to fix the lodash CVE in a repository; the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. For a portal team, you would run the same /scan . against the portal or its integration service and ask the assistant to move a flagged component to its fixed version, approving each step.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. It is the same principle as the tenant boundary in step 3: an integration gets a scoped grant that someone chose deliberately, not broad read access to everything.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session. Work is sent to a computer running the Safeguard CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. During an incident, when someone is rotating keys or rebuilding a service under pressure, this is how each command stays visible and approved by a person holding the device.

Click through it at your own pace, or open it full screen.

To try Safeguard on your own repositories, download Safeguard and follow the CLI docs.

Quick check

Sources

• Quest Diagnostics: Form 8-K, Item 8.01, filed 22 October 2026 (SEC EDGAR)
• SEC EDGAR: filing index for accession 0000947871-26-000941
• Quest Diagnostics: "An update on an incident involving one of our systems" (notice and FAQ, as of 12:00 pm ET, 22 October 2026)
• Quest Diagnostics: Quanum Lab Services Manager product page
• SEC: Statement by Erik Gerding, Director, Division of Corporation Finance, on disclosure of cybersecurity incidents, 21 May 2024
• SEC: Fact sheet, Public Company Cybersecurity Disclosures; Final Rules (PDF)
• 45 CFR 164.402: definitions (Cornell LII)
• 45 CFR 164.404: notification to individuals (Cornell LII)
• 45 CFR 164.406: notification to the media (Cornell LII)
• 45 CFR 164.408: notification to the Secretary (Cornell LII)
• 45 CFR 164.410: notification by a business associate (Cornell LII)
• 45 CFR 164.412: law enforcement delay (Cornell LII)
• 45 CFR 164.414: burden of proof (Cornell LII)
• SecurityWeek (Associated Press): Quest Diagnostics reports cyber breach affecting "certain patient records," 23 October 2026
• BankInfoSecurity: Quest Diagnostics reports hack on IT system used by clients, 22 October 2026
• Fox Business: Quest Diagnostics confirms patient information accessed in cyberattack, 22 October 2026

Last reviewed: 23 October 2026. This is a developing story; check the linked advisories for the latest status.