When the Evidence Had No Signature

Every safety and security standard I work with has some version of the same sentence: data used to make a consequential decision shall be protected against undetected alteration. The Applied Biosystems human-identification workflow has been making the most consequential decisions a laboratory can make — who was at the scene, whose child this is, which sample is whose — on a file format that has never carried an integrity check. Not a weak one. Not a deprecated one. None.

On August 4, 2026, CISA published ICS Medical Advisory ICSMA-26-216-01 against Thermo Fisher Applied Biosystems Genetic Analyzers. One CVE, CVE-2026-17583, CVSS v3.1 base 8.4 (High) with vector AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and CVSS v4.0 base 8.2. The weakness class CISA assigned is CWE-353, Missing Support for Integrity Check. (CISA advisory.)

The advisory's impact sentence is one line: "Successful exploitation of this vulnerability could allow an attacker to modify .fsa/.hid output files, tampering with DNA data and resulting in inaccurate DNA test results."

That is a remarkably calm way to describe it. Let me put the rows in the table.

1. The public record

What the vendor said. Thermo Fisher's security bulletin, dated July 31, 2026, states that .fsa and .hid output files can be modified before the analysis software loads them, and that the changes would be nearly undetectable if laboratory controls were circumvented. The remediation across five supported product lines is the introduction of digital signatures on the instrument software, which the vendor says will help customers verify "moving forward" that data files have not been changed. (The Hacker News, reporting on the July 31 bulletin.)

What got fixed, and what did not. Five product lines received updates:

| Product line | Affected versions | Fixed in | |---|---|---| | 3500 / 3500xL Series Data Collection Software | 4.0.2 and earlier | 4.0.3 | | 3730 / 3730xL Series Data Collection Software | 5.0.2 and earlier | 5.0.3 | | SeqStudio Genetic Analyzer Data Collection Software | 1.2.5 and earlier | 1.2.6 | | SeqStudio Flex Series Instrument Software | 1.2.0 and earlier | 1.2.1 | | GeneMapper ID-X Software | 1.7.3 and earlier | 1.7.4 |

Three more product lines are listed as affected and receive nothing, because they are end-of-life: 3130 Series Data Collection Software 4.1 and earlier, ABI PRISM 3100/3100-Avant Data Collection Software 2.0 and earlier, and ABI PRISM 310 Data Collection Software 3.1 and earlier. (CISA advisory.) Those instruments are still in service in plenty of laboratories, and the vendor's answer for them is procedural.

What the researchers demonstrated. Nathaniel Adams, Kevin Dyer, and Laura Gaydosh-Combs reported the issue to CISA. Adams, a systems engineer at Forensic Bioinformatics, told the Wall Street Journal that his first successful file modification took about 45 minutes using a general-purpose AI coding assistant, working from a public data set. In a demonstration the Journal observed, his code combined electropherogram scans from two individual DNA profiles into a single new file that appeared untouched since 2015. The modified file raised no warning in analysis software used by many laboratories. (The Hacker News summary of the WSJ reporting; Rescana CVE analysis.)

Scope. The researchers assess that the weakness has existed in digital files produced by these instruments since roughly 1995, and that they have not found a reliable way to detect prior tampering after the fact. Thermo Fisher's bulletin does not confirm that historical scope, and does not explain whether or how files generated before the update can be validated retroactively. (The Hacker News.)

Exploitation. None known. CISA states that no public exploitation targeting this vulnerability has been reported and that it is not remotely exploitable. Thermo Fisher told the Journal it knows of no instances of exploitation. The CVE is not in CISA's Known Exploited Vulnerabilities catalog. (CISA advisory; Rescana.)

That last paragraph is the part I want to flag before anything else, because it is where the reasoning usually goes wrong. "No known exploitation" is not a risk statement about this defect. It is a statement about detection capability. The whole finding is that tampering leaves no trace the tooling can see. An absence of detections from a system that cannot detect is not evidence of an absence of events. Any security risk assessment that credits "no known exploitation" as an occurrence-reducing argument here has committed a circular-reasoning error, and a competent assessor should reject it.

2. The standards lens

This instrument sits at an awkward junction. The same hardware and file format serve forensic human-identification casework, paternity and relationship testing, clinical diagnostics, and research. Which standard binds depends on the use, and the vendor cannot control which use a given customer picks. So the correct lens is the intersection, not any single framework.

IEC 81001-5-1:2021, §4.1.2 and §5.3 — security in the health software life cycle. This is the health-software counterpart to IEC 62443-4-1, and it is explicit that the manufacturer shall define security requirements derived from a threat model of the product's intended operational environment, and shall apply secure design principles including defense in depth and protection of data integrity at rest and in transit. A file format whose consumer performs no authenticity check is a §5.3 secure-design finding, not a §6 patch-management finding. The threat model question — what does an adversary with filesystem access to the instrument workstation gain? — has an obvious answer that has been available since the format was designed.

AAMI TIR57 and ISO 14971:2019 — the security-to-safety bridge. TIR57 exists precisely to route a security finding into the ISO 14971 risk file when the security property has a safety or clinical consequence. Here the harm channel is incorrect diagnostic or evidentiary output, which in the clinical branch of use maps to a misdiagnosis or a misattributed sample, and in the forensic branch maps to something ISO 14971 has no vocabulary for at all. That vocabulary gap is real and it matters: the harm is to a third party who is not the patient, is not a user, and never touches the device.

IEC 62304 — software safety classification, applied honestly. For the clinical-diagnostic use of these instruments, the software is plausibly Class B under §4.3 — non-serious injury is possible, and the analytical result is normally subject to independent technical review before it reaches a clinician. I want to be careful here rather than inflate: this is not a Class C infusion-pump scenario where the software drives an actuator into a patient. The severity comes from the decision the output feeds, not from the device's own energy. But §5.2.2 still requires that software requirements include, where relevant, requirements for data integrity — and §5.3.3 requires the architecture to identify segregation necessary for risk control. An unsigned output artifact fails both.

ISO/IEC 17025:2017, §7.11 — control of data and information management. This is the clause with the sharpest edge, and it binds the laboratory, not the vendor. §7.11.3 requires that a laboratory information management system be protected from unauthorized access and safeguarded against tampering and loss. An accredited forensic or calibration laboratory has been signing an attestation to that clause for years while running a workflow in which the primary evidentiary artifact carried no tamper-evidence property whatsoever. The corresponding clinical-laboratory requirement lives in ISO 15189:2022 §7.6 (management of laboratory information). Neither the vendor nor the accreditation body owned this; each assumed the other did.

21 CFR Part 11 — and the licensing footnote that gives the game away. §11.10(a) requires validation of systems to discern invalid or altered records, and §11.10(e) requires secure, computer-generated, time-stamped audit trails. Look at the remediation notes for the SeqStudio Flex line: laboratories using it with security, audit, and electronic signature (SAE) enabled must first install the latest SAE profile on the SAE Admin Console. (CISA advisory.) Read that carefully. The Part 11 integrity apparatus existed. It was a configurable, separately administered feature layered around the workflow — not a property of the artifact. That is the whole finding in one sentence.

IEC 62443-4-2, CR 3.4 — software and information integrity. CISA routed this through the ICS advisory channel, which invites the 62443 component lens. CR 3.4 requires the component to provide the capability to protect against, and to detect, unauthorized changes to information at rest. There is no security level under CR 3.4 at which "no check" is compliant. SL-C 1 already requires the capability to detect.

FBI Quality Assurance Standards for Forensic DNA Testing Laboratories (2020). The QAS require documented technical review of casework data. Technical review is a human control, and human controls have a documented detection capability. When the researchers report they found no reliable way to detect tampering post hoc, they are telling you the detection credit assigned to technical review for this failure mode is approximately zero. If your risk file credits technical review as a detection control against deliberate file alteration, that credit is now falsified by evidence and must be removed.

3. A worked snippet — the threat scenario nobody wrote down

Here is the TARA-style row set I would expect in an IEC 81001-5-1 §5.2 threat model for this product. Feasibility uses the attack-potential scheme familiar from ISO/SAE 21434 Annex G (elapsed time, expertise, knowledge of item, window of opportunity, equipment), which transfers cleanly to health software.

| ID | Asset | STRIDE | Threat scenario | Attack path | Impact | Attack feasibility | Risk | |---|---|---|---|---|---|---|---| | TS-HID-01 | .fsa / .hid electropherogram file at rest | Tampering | Adversary alters allele peak data in a stored run file so that analysis software renders a different genotype | (1) Obtain local or remote logical access to instrument workstation or lab file share. (2) Locate target run file. (3) Rewrite scan channel data and preserve declared file metadata. (4) Return file to expected path. | Incorrect genotype accepted as authentic; wrongful inclusion or exclusion of an individual | High — no specialist equipment; public format documentation; researcher reports first working modification in about 45 minutes with commodity AI tooling | Severe | | TS-HID-02 | .fsa / .hid file provenance metadata | Spoofing | Adversary backdates a fabricated file so it appears to predate the current custody window | Craft file with historical creation timestamp; no cryptographic binding of content to time or to originating instrument | Fabricated evidence survives chain-of-custody paperwork review | High — same access, no additional expertise | Severe | | TS-HID-03 | Analysis-stage integrity decision | Repudiation | Genuine analyst work becomes indefensible because the workflow cannot demonstrate a file was not altered | Inherent: absence of verification means absence of proof in either direction | Every historical case result loses its integrity assurance argument | Not applicable — this is a design consequence, not an attack | Severe | | TS-HID-04 | End-of-life instrument population | Tampering | Same as TS-HID-01 on 3130, 3100 and 310 series, with no vendor fix available | Identical path; remediation limited to procedural and network controls | Same as TS-HID-01, with no technical control available | High | Severe, no vendor mitigation |

TS-HID-03 is the row that does the most damage and the one least likely to appear in anybody's threat model, because it is not an attack. It is what happens to your assurance argument when the integrity property was never there. Every result produced before the update now rests on procedural custody alone.

Fault tree: undetected altered profile reaches a consequential decision

                 TOP EVENT: Altered DNA profile accepted
                       as authentic by decision-maker
                                  |
                                [AND]
                                  |
        +-------------------------+-------------------------+
        |                         |                         |
   IE-1 File is                IE-2 Alteration          IE-3 Result is
   successfully altered        is not detected          acted upon
        |                         |                         |
      [OR]                      [AND]                     [OR]
        |                         |                         |
  +-----+-----+       +-----------+-----------+       +-----+-----+
  |           |       |           |           |       |           |
BE-1        BE-2    BE-3        BE-4        BE-5    BE-6        BE-7
Local       Remote  No crypto   Metadata    Technical Court/     Clinical
filesystem  share   integrity   is          review    tribunal   report
access on   access  check on    self-       cannot    admits     issued
instrument  to run  file open   asserted    detect    result
workstation files   (CWE-353)   (no bind    content
                                to instr.)  edits

  NOTE: BE-3 has probability 1.0 on all affected versions.
        BE-4 has probability 1.0 on all affected versions.
        BE-5 detection credit is unquantified and, per the
        reporting researchers, likely near zero for a
        competent edit.

  Consequence: the AND gate at IE-2 does not reduce risk.
               All three of its inputs are permanently TRUE.

That is the structural point. IE-2 is drawn as an AND gate because a well-designed workflow should require three independent things to fail before an alteration goes unnoticed. On the affected versions, all three inputs are constants. The gate is decorative. Any FTA that showed IE-2 contributing risk reduction was computing a number that did not exist in the product.

4. Derived requirements (excerpt)

These are the five requirements I would put in the security requirements specification, with the numeric commitments a verification engineer can actually test. Each is traceable to a threat scenario above and to a clause.

| ID | Requirement | Traces to | Verification method | |---|---|---|---| | SR-HID-001 | The instrument data collection software shall generate, at file-close time and before the file is made visible on any shared path, a detached cryptographic signature over the complete byte content of each .fsa and .hid output file, using an approved signature algorithm with a minimum 128-bit security strength (for example ECDSA P-256 with SHA-256, or RSA-3072 with SHA-256). The window between file-close and signature availability shall not exceed 2 seconds. | TS-HID-01; IEC 81001-5-1 §5.3; IEC 62443-4-2 CR 3.4 | Test: instrument a run, sample the shared path at 100 ms intervals, confirm no unsigned interval exceeding 2 s. Review: algorithm selection record. | | SR-HID-002 | The signature payload shall cryptographically bind the file content to (a) the originating instrument serial number, (b) the software version and build identifier, and (c) an RFC 3161 trusted timestamp obtained from a laboratory-designated timestamp authority. Where the timestamp authority is unreachable, the software shall record a signed local timestamp and flag the file as TSA_UNAVAILABLE in the verification result. | TS-HID-02; 21 CFR 11.10(e); ISO/IEC 17025 §7.11.3 | Test: verify all three fields present and bound; test TSA-unreachable branch and confirm flag propagates to the analysis UI. | | SR-HID-003 | Analysis software shall verify the signature of every .fsa and .hid file at load time and shall render one of exactly three verification states in the primary analysis view before any genotype call is displayed: VERIFIED, UNVERIFIED_LEGACY (no signature present), or FAILED (signature present and invalid). A FAILED state shall block export of any report from that file without an explicit, logged, role-restricted override. | TS-HID-01, TS-HID-03; IEC 62304 §5.2.2; 21 CFR 11.10(a) | Test: load one file of each class; confirm state rendering precedes genotype display; confirm export block and override logging. | | SR-HID-004 | The software shall not, under any configuration, present an aggregate "valid" indication for a data set containing one or more UNVERIFIED_LEGACY or FAILED files. Verification state shall be reported per file and shall propagate to every downstream report artifact that incorporates data from that file. | TS-HID-03; ISO/IEC 17025 §7.11.3; IEC 81001-5-1 §5.3 | Test: mixed-state batch; confirm no aggregate green state; confirm per-file state appears in exported report. | | SR-HID-005 | For instrument platforms with no available signing update, the manufacturer shall publish a standalone verification utility and a documented file-integrity baselining procedure enabling a laboratory to compute and externally escrow a content hash for each existing file, and shall state in the product security documentation that files produced before baselining carry no integrity assurance. | TS-HID-04; IEC 81001-5-1 §6 (product support); ISO 14971 §7 residual risk disclosure | Review: utility available and documented. Test: utility detects a single-byte modification in a legacy file with 100% detection rate over a 1,000-file corpus. |

SR-HID-005 is the uncomfortable one and the one most likely to be dropped. "End of life, no update provided" is a supportable business decision. It is not, by itself, a discharged safety or security obligation. ISO 14971 §7 and IEC 81001-5-1 §6 both expect residual risk to be disclosed to the user in terms the user can act on, and "your historical case files have no integrity assurance and we cannot give you one retroactively" is the disclosure that matters here. It has not been made in those words.

5. What the headline really tells us

The headline version of this is "DNA software had a security flaw." That framing puts the story in the patch-management bucket, where it will be closed by an update ticket and forgotten.

The engineering version is narrower and much less comfortable. The integrity property was never a property of the artifact. It was assumed to live somewhere else — in the physical chain of custody, in the badge reader on the laboratory door, in the technical reviewer's judgment, in an optional Part 11 audit module that some sites licensed and some did not. Each of those controls is real. None of them binds a signature to the bytes. So when the bytes moved between a badge-controlled instrument and a badge-controlled reviewer, they crossed a gap in which nothing at all was watching them, and they crossed it for thirty years.

That is a specific missing artifact, and it is one I can name: a security requirement, in the requirements specification, stating that the output file shall carry a verifiable integrity property that the consuming software checks and reports. One row. It would have cost a signing key, a verification call, and a status field in a UI. Its absence is now a question mark over an unbounded number of closed cases and clinical reports, with no technical means of resolving it either way.

The generalizable lesson has nothing to do with genetics. Go find the artifact your organization's most consequential decision rests on — the calibration record, the flight-test data file, the coordinate measuring machine output, the model weights, the log your incident review will read. Ask one question: what, specifically, would tell me this file is byte-identical to what the instrument produced? If the answer is a description of who had access rather than a cryptographic property of the file, you have the same finding. You just have not had a researcher spend 45 minutes proving it yet.

— Jherrod Thomas, The Lion of Functional Safety™