FDA Security Control Categories: What Reviewers Expect Per Category

The FDA's February 3, 2026 final premarket cybersecurity guidance is unusually explicit about the security controls reviewers expect to see. It does not list every control. It lists 8 control categories that every cyber device must cover, each with category-specific expectations. This guide walks the 8 categories with what counts as adequate evidence in each, where each lives in eSTAR v7.1, the standards anchor, and the deficiency pattern that follows when a category is thin.

Last updated: June 2026 · Aligned to the FDA's February 2026 final guidance and Section 524B of the FD&C Act.

The 8 categories at a glance

"Group" numbers refer to our eSTAR attachment groups, which are our packaging, not eSTAR field names. See the eSTAR v7.1 mapping guide.

Every category must be (a) described in Group 6 (Controls), (b) traced back to the threats it mitigates in Group 3 (Threat Model), and (c) verified by test evidence in Group 7 (Testing). A control described without test evidence is one of the most-cited Group 6 deficiency patterns.

Why these 8 categories, and why this matters

The Feb 3, 2026 final guidance frames cybersecurity controls as a coverage problem: every threat in the model needs at least one control, and every control needs at least one test. The 8 categories are the FDA's preferred axis to organize that coverage. Reviewers use them as a checklist.

The same 8 categories show up in IEC 81001-5-1 §6 and AAMI SW96:2023 §6 with slightly different naming. The structure is the same.

---

1. Authentication

What it covers. How the device proves the identity of any entity that interacts with it, clinician, patient, service technician, manufacturer, paired mobile app, cloud back-end, machine-to-machine integration.

Expected evidence.

• Identity model for every account class on the device
• Credential lifecycle (issuance, rotation, revocation)
• Multi-factor where the threat model requires it (especially admin/service roles)
• Account lockout, rate limiting on credential endpoints
• Default-credential elimination, no shared defaults that survive deployment
• Test evidence (Group 7) for each authentication surface, both negative and positive cases

Common deficiency. "Provide evidence that default credentials are eliminated at deployment and that the service-account credentials are rotatable."

Standards anchor. OWASP ASVS 2; NIST SP 800-63B; IEC 81001-5-1 §6.1.

2. Authorization

What it covers. Role-based access control (RBAC), least-privilege enforcement, separation of duties, and authorization decisions across every interface, UI, API, service, debug.

Expected evidence.

• Role matrix showing every privilege/action and which role(s) may invoke it
• Service-account scoping (machine identities get only the privileges they need)
• Multi-tenant isolation where applicable
• Test evidence proving that role A cannot perform role B's actions (horizontal and vertical)
• Audit hooks (see Category 6) for sensitive privileged actions

Common deficiency. Horizontal authorization gaps (IDOR) on REST/GraphQL APIs, typically surfaced by a pen tester. The deficiency is usually phrased as "Provide test evidence for role separation between [role A] and [role B]."

Standards anchor. OWASP ASVS 4; IEC 81001-5-1 §6.1; NIST SP 800-53 AC.

3. Cryptography

What it covers. Algorithm selection, key generation and lifecycle, key storage, certificate handling, transport encryption, data-at-rest encryption, and validated-module status where required.

Expected evidence.

• Algorithm inventory (no MD5, SHA-1 in signatures, DES, RC4; no ECB mode; AES-GCM/ChaCha20-Poly1305 for AEAD; ECDSA/EdDSA over weak RSA)
• Key generation (entropy source, RNG validation)
• Key storage (HSM, TPM, secure element, OS keystore, never plaintext in flash)
• Key rotation procedure with evidence it can be performed without clinical disruption
• TLS configuration (TLS 1.2 minimum, prefer 1.3; secure cipher suites; certificate validation; pinning where applicable)
• FIPS 140-3 validation status for the cryptographic module, with the NIST CMVP certificate reference where claimed

Common deficiency. "Provide FIPS 140-3 validation status for the cryptographic module used for [function]", most often raised when a sponsor implies FIPS validation without naming the validated module.

Standards anchor. FIPS 140-3; NIST SP 800-131A; NIST SP 800-57.

4. Code, data, and execution integrity

What it covers. Three closely-related properties: that the code running on the device is the code the manufacturer signed, that the data is the data the device wrote, and that the execution path cannot be diverted or hijacked.

Expected evidence.

• Secure boot with measured/verified chain (root of trust → bootloader → kernel → application)
• Signed application binaries and signed configuration
• Signed-update verification (overlaps with Category 8)
• Data integrity at rest (hashes / authenticated encryption for clinical data)
• Memory-safety posture (memory-safe language where possible; mitigations like ASLR, DEP, stack canaries, CFI for unsafe-language code)
• Anti-rollback / version monotonicity to prevent re-flashing of vulnerable signed versions

Common deficiency. Missing rollback protection, "Provide evidence that the update mechanism prevents downgrade to a vulnerable signed version."

Standards anchor. NIST SP 800-193; IEC 81001-5-1 §6.5; NIST SSDF PS.

5. Confidentiality

What it covers. Protection of clinical data, PHI, configuration secrets, and any device-internal information that would be sensitive in the threat model.

Expected evidence.

• Data classification inventory (what is sensitive; what is not)
• Encryption at rest for sensitive data (and a documented exception list for what is not encrypted, with rationale)
• Encryption in transit on every interface that carries sensitive data
• Secrets management, credentials, API keys, signing keys never logged, never returned in API responses, never exposed in memory dumps
• HIPAA / GDPR alignment where the device handles regulated data

Common deficiency. Secrets discovered in logs or memory during pen test. "Provide evidence that cryptographic keys and service credentials are not exposed in device logs."

Standards anchor. IEC 81001-5-1 §6.2; OWASP ASVS 6, 8; NIST SP 800-53 SC.

6. Event detection and logging

What it covers. What the device records, how long it retains it, how it protects logs from tampering, and what is available to investigate an incident.

Expected evidence.

• Log catalog, what events are logged at what severity (authentication attempts, privilege changes, configuration changes, update events, security-relevant errors)
• Retention policy with documented duration and storage location (local + remote where applicable)
• Tamper resistance, append-only logs, signed logs, or off-device logging
• Time synchronization (NTP source, drift bounds)
• Privacy review, logs do not contain PHI or credentials
• Operator access, how a hospital can retrieve logs for an incident
• Alignment with the MDS2 / HSCC disclosure (audit logging section)

Common deficiency. "Provide log retention policy and evidence that authentication failures are recorded with sufficient detail to support incident investigation."

Standards anchor. IEC 81001-5-1 §6.6; NIST SP 800-92.

7. Resiliency and recovery

What it covers. The device's ability to maintain or safely degrade clinical function under cyber stress, and its ability to recover to a known-good state after an incident.

Expected evidence.

• Fail-safe / fail-secure analysis, what happens to clinical function if the network is hostile, the cloud is unreachable, the update fails, or a component crashes
• Denial-of-service resistance, rate limits, watchdog timers, resource quotas
• Backup and restore procedures, with evidence of tested recovery
• Incident response runbook with operator-facing steps
• Postmarket monitoring integration so resiliency events are observable

Common deficiency. "Provide analysis of clinical function under denial-of-service conditions on [interface]."

Standards anchor. IEC 81001-5-1 §6.7; AAMI SW96:2023 §5.4 (impact on essential performance); NIST SP 800-34.

8. Updatability and patchability

What it covers. The most consequential category in the 2026 guidance. Section 524B(b)(2) makes patchability a statutory requirement, the device must be updatable "in a reasonably and reliably timely manner."

Expected evidence.

• Signed-update path with cryptographic verification (overlaps with Categories 3 and 4)
• Update channel authentication (so attackers cannot impersonate the update server)
• Anti-rollback enforcement
• Failure-mode safety, partial updates do not brick the device or leave it in an unsafe state
• Documented SLA: time from CVE disclosure → patch availability → patch deployment
• Operator-side documentation in labeling
• Evidence the update mechanism has been tested, not just described, typically a custom test harness against the update endpoint

Common deficiency. "Provide evidence of patchability demonstrating compliance with Section 524B(b)(2)", usually issued when the submission describes the mechanism but shows no test results exercising it. See our companion post on patch and update mechanism testing.

Standards anchor. Section 524B(b)(2); NIST SP 800-193; IEC 81001-5-1 §9.4.

---

How to organize Group 6 around the 8 categories

The cleanest Group 6 attachments we have seen follow this layout:

1. Cover summary, table of the 8 categories with one-line status (covered / partial with rationale / not applicable with rationale)
2. One section per category with: scope statement → design description → controls implemented → standards mapped → threats addressed (Group 3 IDs) → test evidence pointer (Group 7 IDs)
3. Traceability matrix appendix, every threat in Group 3 → control(s) in Group 6 → test(s) in Group 7 → residual risk in Group 4

The "not applicable" cells are the highest-risk for deficiencies. A reviewer who sees "Confidentiality, not applicable" without a clear rationale will issue an AI request. The fix is to write the rationale once, well, and tie it to the threat model.

How Blue Goat Cyber builds Group 6 packages

We build Group 6 attachments against this 8-category structure. Every category gets a scoped narrative, a control list mapped to recognized standards, threat traceability back to Group 3, and test-evidence pointers into Group 7. We write the "not applicable" rationales explicitly so reviewers do not need to ask. Our pen testers exercise every category as part of Group 7 so the test evidence is real, not theoretical.

If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. See our cybersecurity submission services and the new testing requirements taxonomy.

FAQ

Are the 8 categories mandatory or recommended?

The FDA's guidance frames them as expected coverage. In practice reviewers treat them as mandatory: a submission missing a category, or marking one "not applicable" without rationale, draws a deficiency. Section 524B makes one of the 8, updatability/patchability, explicitly statutory.

Can one control satisfy multiple categories?

Yes. A signed-update mechanism, for example, supports authentication (of the update source), cryptography (signature verification), code integrity (only signed code runs), and updatability/patchability. List the control once and reference it from each category it supports.

How is this different from a generic security control catalog like NIST 800-53?

NIST 800-53 is comprehensive; the FDA's 8 categories are the subset the medical-device guidance specifically calls out as coverage axes. The two are compatible, most 800-53 controls map cleanly to one or more of the 8 categories. Use 800-53 (or ISO 27002, or IEC 62443) as the underlying catalog and the 8 categories as the reporting structure.

Where does the cybersecurity bill of materials fit?

The SBOM (Group 5) supports the cryptography category (third-party crypto libs) and the updatability category (component-level update tracking), and it underlies the vulnerability analysis that backs every other category. The SBOM does not live in Group 6 itself.

Do SaMD products need all 8 categories?

Yes, with adjusted evidence. A pure SaMD running on commodity cloud will lean on platform controls for several categories (with documented responsibility split), but it still needs a coherent narrative for each of the 8.

Related reading

• eSTAR v7.1 Cybersecurity Attachments mapping guide
• Cybersecurity Management Plan for FDA Submissions
• FDA Cybersecurity Testing Requirements Taxonomy
• Patch & Update Mechanism Testing for Section 524B(b)(2)
• STRIDE Threat Modeling for Medical Devices
• Security Risk Assessment under IEC 81001-5-1
• The SPDF Playbook

References

Primary sources cited or relied on in this guide:

• Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (Feb 2026 final), U.S. FDA
• ANSI/AAMI SW96:2023, Standard for Medical Device Security, AAMI/ANSI
• IEC 81001-5-1:2021, Health software and health IT systems safety, effectiveness, and security, IEC/ISO
• NIST Cybersecurity Framework 2.0, NIST
• ISO 14971:2019, Application of risk management to medical devices, ISO