Authentication

Authentication for Medical Devices

Purpose

Define secure user/device authentication, session management, and RBAC suitable for medical device risk profiles.

When to Apply

• User login, device-to-cloud or device-to-device auth, local service access.
• Any control or PHI access path.

Requirements (testable)

1. Unique Identities: No shared accounts; per-user/per-device identifiers. Rationale: accountability.
2. Credential Protection: Store secrets hashed with strong KDF (argon2/bcrypt/scrypt) for users; protect device keys in secure element/TPM if available. Rationale: resist compromise.
3. MFA Where Feasible: Apply MFA for remote administrative access and high-risk actions. Rationale: reduce takeover risk.
4. Mutual Authentication: Use mTLS or equivalent for device↔server; verify server certs; validate device cert. Rationale: prevent MITM/rogue services.
5. Session Management: Short-lived tokens; refresh with rotation; revoke on logout/compromise; bind tokens to device/user context. Rationale: limit exposure.
6. RBAC: Enforce least privilege roles; gate safety-critical actions to authorized roles; log privilege escalations. Rationale: control misuse.
7. Rate Limiting/Lockout: Apply rate limits to auth endpoints; lockout/backoff on repeated failures (with clinical safety consideration). Rationale: brute-force resistance.

Recommended Practices

• Use hardware-backed key storage for device identity.
• Rotate credentials/keys; define expiry and revocation process.
• Log auth successes/failures without storing secrets; monitor anomalies.
• Provide offline/maintenance access controls with separate audit trail.

Patterns

Password hashing (server-side example):

# REQ-AUTH-CRED-01; TEST-AUTH-04
hashed = argon2_hash(password, opslimit=4, memlimit=64*1024)

mTLS connection setup (pseudo):

// REQ-AUTH-MTLS-02; TEST-AUTH-06
tls_set_client_cert(ctx, device_cert, device_key);
tls_set_ca(ctx, ca_cert);
tls_require_server_auth(ctx, true);

Role check:

// REQ-AUTH-RBAC-03; TEST-AUTH-08
if (!user_has_role(user, ROLE_CLINICIAN)) return ERR_FORBIDDEN;

Anti-Patterns (risks)

• Shared credentials across users/devices -> risk: no accountability.
• Storing passwords in plaintext or weak hash (MD5/SHA1) -> risk: compromise.
• No server cert validation in TLS -> risk: MITM.
• Long-lived bearer tokens without rotation -> risk: replay/takeover.

Verification Checklist

• Unique user/device IDs; no shared accounts.
• Strong password hashing; device keys protected (secure element/TPM if available).
• MFA applied for high-risk/remote admin actions.
• Mutual auth for device↔server; server certs validated.
• Sessions/tokens short-lived; rotation and revocation implemented.
• RBAC enforced with least privilege; critical actions gated.
• Rate limiting/backoff/lockout with safety-aware thresholds.
• Auth events logged (no secrets); anomalies monitored.

Traceability

• Requirements REQ-AUTH-### mapped to tests TEST-AUTH-###; link to security risk controls and threat model items.

References

• NIST SP 800-63 for auth assurance (informative).
• FDA Cybersecurity Premarket Guidance.
• IEC 62443 identity/authentication requirements.

Changelog

• 1.0.0 (2026-01-04): Initial authentication skill with mTLS, RBAC, MFA, and credential handling.

Audit History

• 2026-01-04: Audit performed. Verified:
  • NIST SP 800-63 reference appropriate for authentication assurance levels
  • KDF recommendations (argon2/bcrypt/scrypt) are current best practices
  • mTLS patterns technically accurate