FDA Security Requirements Testing: The 2026 Verification Guide

Most cybersecurity deficiency letters in this area come from a single mistake: the manufacturer treats "security testing" as one deliverable, commissions a penetration test, and files that report against every testing expectation in the submission. The February 3, 2026 final guidance does not work that way. It enumerates distinct categories of testing evidence, and the first one is not something an external lab can produce.

Aligned to the FDA's February 2026 final premarket cybersecurity guidance and Section 524B of the FD&C Act.

Why this matters

Section 524B(b)(2) of the FD&C Act requires manufacturers to design, develop, and maintain processes that provide a reasonable assurance the device and related systems are cybersecure. The February 3, 2026 final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, is the operative interpretation reviewers apply, and it frames security testing as evidence generated inside a Secure Product Development Framework rather than as a one-time external assessment.

That framing has a consequence teams underestimate. Security testing evidence is quality system output. It is traceable to design inputs, produced under design controls in 21 CFR 820.30, and reviewed by the FDA in the same frame as any other verification and validation record. When a submission contains only an outside report, the reviewer sees an assessment with no anchor in the design history file, and the natural deficiency follows: show us the requirements, show us they were implemented, show us how you tested the boundaries.

The four testing categories the guidance expects

The guidance's premarket testing section lists these as separate deliverables:

What security requirements testing actually is

Security requirements testing is verification in the classic design-controls sense. You wrote security requirements as design inputs. You built the device. Now you demonstrate, requirement by requirement, that the built device implements each one as specified.

Concretely, the evidence package contains:

• A list of the security design input requirements, each with a stable identifier that appears in your traceability matrix.
• A test case or set of test cases per requirement, with the pass criteria written in advance.
• Results tied back to the requirement identifiers, so a reviewer can walk from any requirement to its evidence without asking you for a mapping.
• Boundary analysis, plus the rationale for the boundary assumptions used.
• Disposition of anything that did not pass, either fixed and retested, or carried into the residual-risk argument with justification.

The requirements themselves come from your threat model, your security risk assessment, and the control expectations in the guidance: authentication, authorization, cryptography, secure update and rollback, logging and detection, resiliency and recovery, and the interface-specific controls your architecture views describe.

Boundary analysis, and why the rationale matters more than the numbers

Boundary analysis is the part of this deliverable that separates a credible package from a checkbox exercise, and it is where most teams under-document.

Every security requirement has implicit limits. A session timeout requirement has a minimum and maximum. A key length requirement has an accepted floor. A rate-limit control has a threshold that separates normal clinical use from abuse. A buffer has a maximum accepted input size. Requirements testing has to exercise the values at and around those limits: at the boundary, one step inside, one step outside, and at the invalid extremes.

The guidance goes further than asking for the test results. It asks for the rationale behind the boundary assumptions. That is a claim about your device's intended use, not about your code. It says: this is the maximum realistic number of concurrent clinical users, so this is the rate limit; this is the longest a clinician can be away from the console mid-procedure, so this is the session timeout; this is the largest legitimate payload this interface receives from the hospital system, so this is the input size ceiling.

A reviewer evaluating that rationale is checking whether your boundaries were derived from the clinical workflow and the threat model, or picked because they were the framework defaults. The second one draws questions.

Why this one cannot be outsourced

Here is the structural reason a security firm cannot sign this deliverable for you.

Security requirements testing verifies the device against your design inputs, held in your quality system, under your design controls. An external tester has no visibility into that. They do not hold your requirement identifiers, your traceability matrix, your design history file, or the clinical rationale that justified your boundary assumptions. They can be shown a copy of a requirements document, but reviewing a document is not the same as attesting that the design inputs were correct, complete, and correctly implemented under a quality system they do not operate.

The honest division of labor:

• The manufacturer owns the security requirements, the traceability matrix, the boundary assumptions and their clinical rationale, the verification protocols, and the signed verification records.
• An external testing partner can build test harnesses, execute protocol-level and interface-level tests against nominated boundaries, and report findings as inputs to your verification records. What the partner signs is its own scope, method, and results.
• Nobody outside your quality system should be attesting that your design inputs were satisfied. If a vendor offers to, that attestation is worth less than it sounds and it will not survive a reviewer question about where the requirements came from.

This is not a limitation to work around. It is the reason the deliverable exists: the FDA wants to see that security was engineered into design controls, not inspected in afterwards.

Penetration testing: the other end of the spectrum

Penetration testing asks a different question. Not "did we build what we specified," but "what can someone do to what we built."

It is adversarial, it is threat-model-driven rather than requirements-driven, and it deliberately looks for behavior nobody specified. The 2026 guidance expects the report to document tester independence and expertise, scope, duration, methods, and results. Independence matters because a tester who helped write the requirements will unconsciously test inside them, which is precisely the blind spot the exercise is meant to cover.

The most valuable findings from a good penetration test are the ones that were never in the requirements at all: a chained path that combines two individually acceptable behaviors, a debug interface nobody documented, a maintenance credential shipped in the field image. No amount of requirements verification surfaces those, because requirements verification only proves the specified thing works.

For scope and depth, see the penetration testing guide and the 510(k) pen test scoping guide.

Threat mitigation testing sits between them

Threat mitigation testing is the bridge, and it is the category teams skip most often.

Your threat model identifies threats and assigns risk controls. Threat mitigation testing demonstrates that each of those controls is effective on the built device. It is not "the requirement was implemented" (that is requirements testing) and it is not "an adversary tried everything" (that is penetration testing). It is: this specific control was intended to mitigate this specific threat, and here is the evidence that it does.

The traceability chain reviewers follow runs threat, to risk control, to design input requirement, to verification evidence, to mitigation effectiveness evidence. A break anywhere in that chain is a deficiency. See the threat modeling guide for the upstream half.

How to file all four in eSTAR

All four categories belong in the cybersecurity testing attachment, and they should be visibly separated. A single combined report labeled "Security Testing" forces the reviewer to work out which sections satisfy which expectation, and reviewers who cannot find something record it as missing.

Practical structure:

1. A one-page testing summary that names all four categories and points to where each is filed.
2. Security requirements testing: the traceability matrix, the verification protocols and results, the boundary analysis with rationale.
3. Threat mitigation testing: control-by-control effectiveness evidence, cross-referenced to the threat model.
4. Vulnerability testing: SAST, DAST, software composition analysis, fuzzing, and scanning results, with the SBOM and VEX cross-references.
5. Penetration testing: the independent report, with the independence statement, scope, duration, methods, and results.
6. A remediation and residual-risk table covering findings from every category.

For the full slot mapping, see the eSTAR v7.0 cybersecurity mapping guide and the 10-family testing taxonomy.

How Blue Goat approaches this

We scope third-party work to what a third party can legitimately attest to. Penetration testing, vulnerability testing, protocol fuzzing, and control-effectiveness testing are engagements we run and sign, with our own scope, methodology, tester independence statement, and results.

Security requirements testing stays with the manufacturer, because it is verification against design inputs inside a quality system we do not operate. Where teams want help, we work upstream instead: reviewing whether the security requirements set covers the threat model, pressure-testing boundary assumptions against the clinical workflow, and building test harnesses the engineering team executes and records under its own design controls. We will tell you when a deliverable is yours to sign rather than sell you an attestation a reviewer will not credit.

FAQ

Can our penetration test report satisfy the security requirements testing expectation?

No. A penetration test evaluates the built device adversarially against threats. Security requirements testing verifies the device against your documented design inputs, requirement by requirement, with boundary analysis. The two answer different questions, and filing one against both expectations is a recurring deficiency pattern. Reviewers look for the requirement identifiers and the traceability matrix, and a pen test report contains neither.

Who signs the security requirements testing records?

The manufacturer, through whoever your quality system designates for design verification records, typically engineering with quality assurance approval. External partners sign their own scope and results only. No third party should attest that your design inputs were satisfied, because no third party operates the quality system those inputs live in.

What does the FDA mean by boundary analysis?

Testing at, inside, and outside the limits of each security requirement: minimum and maximum accepted values, thresholds, timeouts, key lengths, input sizes, and rate limits. The guidance also asks for the rationale behind the boundary assumptions, meaning the justification, grounded in intended use and the threat model, for why those limits are the right ones for this device.

Do we need requirements testing if we have full SAST and DAST coverage?

Yes. SAST and DAST are vulnerability testing. They find defect patterns and runtime weaknesses, but neither one knows what your security requirements say, so neither can demonstrate that a specific requirement was implemented as specified. They are complementary evidence in a different category.

How much boundary rationale is enough?

Enough that a reviewer can follow the reasoning without asking a question. One or two sentences per boundary that connect the value to the clinical workflow, the intended use environment, or a specific threat in the model. Boundaries stated with no rationale, or justified only as framework defaults, are the version that draws Additional Information requests.

What if a security requirement fails verification?

Fix it and retest, or document it as an accepted residual risk with a justification tied to the security risk assessment. What you cannot do is omit it. Reviewers who find a requirement in your traceability matrix with no corresponding result treat the gap as unresolved, and an unexplained gap is more damaging than a documented and justified one.

CTA

If your submission timeline is close and you are unsure whether your testing evidence covers all four categories the guidance expects, book a review. We will tell you which deliverables are ours to run and which are yours to sign.