---
title: Authentication and Access Control for Medical Devices Under MDR
description: Multi-factor auth, role-based access, session management, and credential storage for MDR-regulated devices, mapped to Annex I §17.4.
authors: Tibor Zechmeister, Felix Lenhard
category: Usability Under MDR
primary_keyword: authentication access control medical device
canonical_url: https://zechmeister-solutions.com/en/blog/authentication-access-control-mdr
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Authentication and Access Control for Medical Devices Under MDR

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **MDR Annex I §17.4 obliges manufacturers to set out minimum IT security measures, including protection against unauthorised access. In practice that means every MDR-regulated software device needs an authentication model, a role-based access control scheme, session management, and a credential storage strategy that survives hostile scrutiny. This post covers what auditors expect to see, and what startups can realistically build.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- MDR Annex I §17.4 requires manufacturers to define minimum IT security measures including protection against unauthorised access. This is the anchor for every authentication and access control requirement on an MDR-regulated device.
- Multi-factor authentication is proportionate for clinician and administrator accounts, and is increasingly the expectation from notified bodies for roles that can change device configuration or access patient data.
- Role-based access control (RBAC) with a small number of clearly scoped roles survives audits better than fine-grained permission models nobody can reason about.
- Session management is the category where most startups leak. Idle timeouts, re-authentication for privileged actions, and safe session termination matter more than the login flow itself.
- Credential storage failures are the easiest audit findings in cybersecurity. Hashed and salted credentials, platform key stores, and no hard-coded secrets in firmware or source code.
- EN IEC 81001-5-1:2022 is the reference standard that operationalises these expectations. MDCG 2019-16 Rev.1 maps them to MDR.

## Why this matters

Of all the cybersecurity sub-topics in the MDR world, authentication and access control is the one where the gap between founder intuition and auditor expectation is widest. Founders tend to think of authentication as a login screen. Auditors think of it as a system property that shows up in requirements, architecture, risk files, verification, and post-market monitoring.

Tibor's experience is that startups rarely fail on the concept of "we need authentication". They fail on the specifics. A hard-coded service account. A shared administrator credential. A session that never expires. A password reset flow that leaks enumeration data. A credential stored in plain text in a configuration file. None of these are exotic attacks. They are the first things a notified body auditor looks for, because they are the first things a real attacker looks for.

Felix has seen founders treat "we use OAuth" as a finished sentence. It is not. OAuth is a protocol, not a security architecture. The question behind the question is always the same: how do you decide who can do what on this device, and what is the evidence that the decision holds up?

## What MDR actually says

MDR Annex I GSPR 17.4 states that for devices incorporating electronic programmable systems and software which are devices in themselves, manufacturers shall set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended. The phrase "minimum requirements concerning IT security measures, including protection against unauthorised access" is the legal hook for everything in this post.

GSPR 17.2 adds the lifecycle context: software shall be developed and manufactured in accordance with the state of the art, taking into account the principles of development life cycle, risk management including information security, verification and validation. Authentication and access control are state-of-the-art disciplines with defined standards, so the "state of the art" clause bites directly.

MDCG 2019-16 Rev.1 maps these provisions to EN IEC 81001-5-1:2022, which defines security activities through the product lifecycle. Access control, authentication, and authorisation are treated as first-class security requirements, not a box in a settings page.

Tibor reads this as a simple expectation: if the device has users, the manufacturer documents how users are authenticated, what they can do once authenticated, how sessions are managed, and how credentials are stored. Nothing in that sentence is optional for an MDR-regulated device.

## A worked example

Consider a web-based clinician portal for reviewing cardiac monitoring data uploaded from a wearable. Three user types are in scope: patients who upload data, clinicians who review it, and administrators who manage the organisation.

A minimum-viable MDR-compliant authentication and access control design for this portal looks like this.

- Patient accounts use single-factor authentication with a strong password policy, platform-managed credential recovery, and a session length capped at four hours of activity. Patients can read their own data only.
- Clinician accounts use multi-factor authentication at every login, with a session length capped at one hour of inactivity and a hard cap of eight hours. Clinicians can read data for patients assigned to their organisation and annotate findings. Clinicians cannot change device configuration.
- Administrator accounts use multi-factor authentication at every login, have a shorter idle timeout of fifteen minutes, and require re-authentication for any action that creates, modifies, or deletes a user. Administrators cannot access raw patient data without triggering an audit log event.
- Device service accounts, used by the wearable itself to upload data, use device-unique credentials provisioned at manufacturing time, stored in the device's secure element, and scoped to write-only access for the device's own telemetry.
- All credentials stored server-side use a modern password hashing function with per-credential salts. No shared administrator account exists. No credential is hard-coded in firmware. No credential appears in server logs.

This is not a complicated design. It is a design that distinguishes between roles, applies MFA proportionate to the risk of each role, manages sessions in a way that reflects clinical workflow, and stores credentials in a way that survives a leaked database. It takes a competent engineer about two weeks to build properly. Tibor's experience is that startups who build this during design have straightforward audits on the authentication topic. Startups who retrofit it after discovering gaps typically need six to eight weeks including re-verification.

## The Subtract to Ship playbook

**Step 1. Enumerate roles before writing any auth code.** A role is a job function, not a permission list. "Clinician" is a role. "User who can read patient X's data" is not. Auditors expect to see roles defined, documented, and linked to intended use. Felix has never seen a startup with too few roles. He has seen many with too many.

**Step 2. Apply MFA proportionate to role risk.** Patients reading their own data need strong single-factor with safe recovery. Clinicians accessing patient data need MFA. Administrators doing anything privileged need MFA with step-up authentication for sensitive actions. "Everyone uses MFA" is a reasonable default once infrastructure supports it, but the auditor's question is always proportionality.

**Step 3. Session management is the quiet killer.** Idle timeouts must match clinical workflow. A one-hour idle timeout for a clinician reviewing a dozen cases is usable. A fifteen-minute idle timeout for a clinician in a consult room is hostile. A no-timeout session for an administrator is an audit finding waiting to happen. Re-authentication for privileged actions is the single cheapest control most startups skip.

**Step 4. Role-based access control beats attribute-based complexity for small teams.** RBAC gives a small number of roles, clearly documented, and auditable in a five-minute review. ABAC and fine-grained permission models are powerful and almost always overkill for a startup's first two years. Tibor's auditor view is that a clean RBAC model is easier to trust than a clever ABAC model.

**Step 5. Credential storage is a one-way decision.** Hash and salt every password with a modern algorithm. Use the platform's secure key store for cryptographic material. Never store a credential in source control, in configuration files, in server logs, in environment variables on a shared host, or anywhere else a developer might read it by accident. The cost of doing this right during architecture is roughly zero. The cost of fixing it after a leak is the cost of the entire company.

**Step 6. Audit logs are part of the control, not an extra.** Every authentication success, every authentication failure, every role change, every administrative action logged with a timestamped, authenticated identity. This is what makes repudiation threats actually addressable and what gives the post-market surveillance process something to look at when users report anomalies.

**Step 7. Link every access control requirement to the ISO 14971 risk file.** Unauthorised access is a hazardous situation. The mitigation is the access control design. The verification is the security test. This is the traceability notified bodies look for, and it is the fastest way to signal "we treat security as part of safety".

**Step 8. Test with an adversarial mindset.** Static analysis catches obvious bugs. The bugs that break authentication are almost always architectural: a forgotten endpoint, a mis-scoped role, a session token leaked in a URL. Pentesting, fuzz testing, and a deliberate review pass by someone who did not write the code are the controls that catch these.

**Step 9. Document the whole thing in one place.** An access control model document that sits inside the software architecture document and links out to the threat model, the risk file, and the verification records. One artefact, one link, one answer to the auditor's question.

## Reality Check

1. Can you list every role in your device and describe, in one sentence each, what each role can and cannot do?
2. Is multi-factor authentication required for every role that can read patient data or change device configuration?
3. Do idle session timeouts reflect the clinical workflow the device is used in, and can you defend the specific values to a notified body auditor?
4. Are privileged actions (creating users, changing roles, exporting data) protected by re-authentication or step-up verification?
5. Are all credentials stored using modern hashing with salts, with no credential ever present in source control, configuration files, or logs?
6. Do your audit logs capture every authentication event, every privileged action, and every role change, with a tamper-resistant store?
7. Is your access control model documented as part of your software architecture, with traceability into the risk file and the verification records?
8. If a disgruntled former employee kept a local copy of your codebase, would any still-active credential survive the next audit?

## Frequently Asked Questions

**Does MDR literally require multi-factor authentication?**
Not in those words. MDR Annex I §17.4 requires minimum IT security measures including protection against unauthorised access, and EN IEC 81001-5-1:2022 plus MDCG 2019-16 Rev.1 interpret this through state-of-the-art security practice. For clinician and administrator roles on connected devices, multi-factor authentication is increasingly the expected state-of-the-art. Skipping it requires a credible justification in the risk file.

**Can a standalone offline device skip authentication entirely?**
Usually no. Even offline devices typically have service accounts, configuration interfaces, and maintenance modes that need authentication. The few genuine single-user offline devices still need to document the decision in the risk file and show it survives the adversarial review. "It is offline" is not a magic word.

**What is the lightest access control model that will survive an audit?**
RBAC with three to five clearly defined roles, proportionate authentication per role, session management that matches workflow, and credential storage that follows the state of the art. Documented in the software architecture. Traced into the risk file. Verified with security tests. Anything lighter than this tends to produce audit findings.

**How do I handle break-glass access for emergencies?**
Design for it explicitly. A break-glass account is a documented role with documented conditions of use, documented audit logging, and documented post-use review. An undocumented shared administrator credential labelled "for emergencies" is an audit finding.

**Is password rotation still recommended?**
Current guidance from multiple authorities has moved away from forced periodic rotation toward detection of compromise and response. The right answer for an MDR-regulated device is to document the policy, justify it against current state-of-the-art sources, and make sure the policy matches the risk file. "We rotate passwords every 90 days because we always have" is not a justification.

## Related reading
- [MDR Annex I GSPR explained](/blog/mdr-annex-i-gspr). The source of the access control obligation.
- [MDR software lifecycle under IEC 62304](/blog/mdr-software-lifecycle-iec-62304). The lifecycle that authentication requirements live inside.
- [SBOM for medical devices under MDR](/blog/sbom-medical-devices-mdr). An authentication library with a known CVE is an access control failure in slow motion.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I, GSPR 17.2 and 17.4.
2. MDCG 2019-16 Rev.1 (December 2019, Rev.1 July 2020), Guidance on Cybersecurity for medical devices.
3. EN IEC 81001-5-1:2022, Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, Activities in the product life cycle.
4. EN 62304:2006+A1:2015, Medical device software, Software life cycle processes.
5. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices.

---

*This post is part of the [Usability Under MDR](https://zechmeister-solutions.com/en/blog/category/usability) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*