Security Requirements Testing vs Penetration Testing

Published September 4, 2026

Teams routinely treat "security testing" as a single line item on the submission plan, commission a penetration test, and file that report everywhere testing evidence is requested. The February 3, 2026 final premarket cybersecurity guidance does not accept that. It expects separate evidence streams, and the first of them is one no outside firm can produce for you.

Why this matters

Section 524B(b)(2) of the FD&C Act requires processes that provide a reasonable assurance the device is cybersecure, and the FDA's February 3, 2026 final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, is the interpretation reviewers apply. It treats security testing as quality system output produced inside a Secure Product Development Framework, not as an external assessment bolted on before filing.

That distinction has teeth. Testing evidence is expected to trace to design inputs under design controls, now ISO 13485 clause 7.3 as incorporated into 21 CFR Part 820 by the QMSR. A submission holding only an outside report gives the reviewer an assessment with no anchor in the design history file, and the deficiency writes itself: show the requirements, show they were implemented, show how the boundaries were tested and why those boundaries are right.

The two activities answer different questions

Security requirements testing asks: did we build what we specified?

It is verification. 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, with test cases written against pass criteria defined in advance and results traceable to requirement identifiers.

Penetration testing asks: what can someone do to what we built?

It is validation, and it is deliberately not bounded by your requirements. The best findings from a penetration test are the ones no requirement ever contemplated: a chained path combining two individually acceptable behaviors, an undocumented debug interface, a maintenance credential in the field image. Requirements verification cannot surface those, because it only proves the specified thing works.

Boundary analysis is the part reviewers read

The guidance does not just ask whether the requirement passed. It asks for boundary analysis and, critically, for the rationale behind the boundary assumptions used.

Every security requirement carries implicit limits. A session timeout has a minimum and a maximum. A rate limit has a threshold separating normal clinical use from abuse. An input handler has a maximum legitimate payload size. Requirements testing exercises values at the boundary, one step inside, one step outside, and at the invalid extremes.

The rationale is a claim about your device's intended use, not about your code. This is the longest a clinician can be away from the console mid-procedure, so this is the timeout. This is the largest legitimate message the hospital system sends this interface, so this is the size ceiling. A reviewer reading that rationale is checking whether the boundaries came from the clinical workflow and the threat model, or from the framework defaults. Defaults draw questions.

Why requirements testing cannot be outsourced

There is a structural reason a security firm cannot sign this deliverable.

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 any of that. They do not hold your requirement identifiers, your traceability matrix, your design history file, or the clinical justification behind your boundary assumptions. Being handed a requirements document is not the same as attesting that the design inputs were correct, complete, and correctly implemented under a quality system you do not operate.

The honest division:

• You own the security requirements, the traceability matrix, the boundary assumptions and their rationale, the verification protocols, and the signed verification records.
• A testing partner owns its own scope, methodology, independence statement, and results. It can build harnesses and execute tests against nominated boundaries, feeding results into your records.
• Nobody outside your quality system should attest that your design inputs were satisfied. An attestation like that will not survive the first reviewer question about where the requirements came from.

That is the point of the deliverable. The FDA wants evidence that security was engineered into design controls, not inspected in at the end.

The two categories in the middle

See also: Fuzz Harness Generation for Medical Device Protocols, BLE & RF Penetration Testing, and Medical Device Penetration Testing Cost: 2026 Guide.

Requirements testing and penetration testing are the ends of the spectrum. The guidance names two more categories between them.

Threat mitigation testing proves that each risk control identified in the threat model is effective on the built device. Not "the requirement was implemented," and not "an adversary tried everything," but: this control was meant to mitigate this threat, and here is the evidence that it does.

Vulnerability testing covers SAST, DAST, software composition analysis against the SBOM, protocol fuzzing, and scanning. These find defect patterns and known weaknesses. None of them knows what your requirements say, so none can stand in for requirements testing.

The chain reviewers trace runs threat, to risk control, to design input requirement, to verification evidence, to mitigation effectiveness evidence, to adversarial validation. A break anywhere is a deficiency.

The deficiency pattern

The recurring version looks like this. The submission contains one well-produced penetration test report. The cybersecurity testing attachment points to it for everything. The Additional Information request comes back asking for security requirements verification with boundary analysis, and for evidence that the risk controls in the threat model were tested for effectiveness. Now the team is generating design-controlled verification records under review-clock pressure, which is the worst possible time to be writing boundary rationale.

The fix is structural, not last-minute. Separate the four categories in your testing summary, name them explicitly, and point to where each one is filed. Reviewers who cannot find something record it as missing.

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, each signed with our own scope, methodology, independence statement, and results.

Security requirements testing stays with the manufacturer, because it verifies design inputs inside a quality system we do not operate. Where teams want support, we work upstream: checking that the requirements set covers the threat model, pressure-testing boundary assumptions against the clinical workflow, and building harnesses your engineering team executes and records under its own design controls.

FAQ

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

No. A penetration test evaluates the built device against adversary behavior. Security requirements testing verifies the device against documented design inputs, requirement by requirement, with boundary analysis. Reviewers look for requirement identifiers and a traceability matrix, and a penetration test report contains neither. Filing one against both expectations is a common deficiency trigger.

Who signs the requirements testing records?

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

What counts as boundary analysis?

Testing at, inside, and outside each requirement's limits: minimum and maximum values, thresholds, timeouts, key lengths, input sizes, rate limits. The guidance also expects the rationale for those boundary assumptions, grounded in intended use and the threat model rather than in framework defaults.

Do SAST and DAST cover requirements testing?

No. Both are vulnerability testing. They find defect patterns and runtime weaknesses without any knowledge of what your requirements specify, so neither can demonstrate that a given requirement was implemented as written. They are complementary evidence in a different category.

What happens if a requirement fails verification?

Fix it and retest, or document it as an accepted residual risk justified against the security risk assessment. Omitting it is the one option that does not work. A requirement sitting in the traceability matrix with no corresponding result reads as unresolved, which is worse than a documented and justified gap.

CTA

Not sure whether your testing evidence covers all four categories the guidance expects? Book a submission review and we will map what you have against what reviewers look for. Full detail lives in the security requirements testing guide.