Multi-factor authentication is one of the most effective controls a patient portal can have, and one of the most common reasons an older patient gives up trying to log in. A text message code that times out before a patient finds their glasses, a biometric scan that fails because of thinner fingerprints, or a security question tied to a password manager nobody set up for them: each of these is a real access failure, not a hypothetical one. This article looks at what actually makes authentication hard for older patients, what HIPAA requires (and does not require) for verifying identity, how NIST's current guidance treats accessibility, and what a healthcare software team can change in the login flow itself without weakening security.
Why Login Screens Become a Barrier for Older Patients
Patient portal adoption among older adults is already uneven, and authentication is consistently one of the points where it breaks down. Research on ageism in healthcare technology design has found that older patients want to use portals but run into interfaces built around assumptions that do not match their actual experience: smaller touch targets, short timeouts, and multi-step verification that assumes a second device is always nearby and fully charged.
A few specific friction points show up again and again:
- One-time codes that expire too quickly. A code that is valid for 60 to 90 seconds does not account for a patient who needs to retrieve a phone from another room, put on reading glasses, or re-read the number twice.
- Biometric sensors with inconsistent accuracy. Fingerprint sensors can struggle with age-related changes in skin texture and ridge depth, and face recognition can be affected by changes in appearance or by caregivers helping at an angle the camera was not designed for.
- Dependence on a single device. Authenticator apps and push notifications assume the patient has a smartphone, keeps it updated, and remembers which device is registered. Shared household devices complicate this further.
- No accessible path to recovery. When login fails, the fallback is often a web form or chatbot, not a phone number a confused or frustrated patient can actually use.
None of this is an argument against strong authentication. It is an argument for designing it so the people most likely to need the portal, including patients managing chronic conditions who benefit most from message threads, refill requests, and result access, are not the people most likely to be locked out of it.
What HIPAA Actually Requires for Authentication
The HIPAA Security Rule's technical safeguards include a standard for person or entity authentication, which requires covered entities and business associates to implement procedures that verify a person or entity seeking access to electronic protected health information is who they claim to be. The regulation does not specify a particular method. It does not mandate SMS codes, biometrics, or any single factor.
That flexibility is intentional. The Security Rule is built around a risk analysis: the organization assesses its own threats, system architecture, and patient population, then chooses safeguards proportionate to that risk. A strong password combined with a recovery process that is itself verified can satisfy the authentication standard, provided the risk analysis supports it and the organization can show its reasoning. This matters for accessibility, because it means a covered entity has room to choose authentication methods that work for its actual patients rather than defaulting to whatever a vendor ships out of the box.
What the Security Rule does not give you is a pass on security in the name of accessibility. The standard still requires a procedure that genuinely verifies identity. The right framing is not "accessible or secure," it is "which combination of accessible methods still produces reliable verification for this patient population," which usually means offering more than one path rather than weakening the one path you have.
NIST's Updated Guidance Narrows the Gap Between Secure and Usable
NIST's Special Publication 800-63B, the federal reference most healthcare software teams build authentication around even without a direct mandate to follow it, was revised in 2025 and shifted the baseline toward phishing-resistant authentication. Under the current guidance, authenticator assurance level 2 (the tier most patient portals should target) requires verifiers to offer at least one phishing-resistant option, and level 3 requires phishing-resistant cryptographic authentication outright. Manually typed codes, including SMS and email one-time passcodes, are explicitly not considered phishing-resistant, though they remain usable as one option among several at lower assurance levels.
What is more directly useful for this topic is that NIST 800-63B dedicates an entire section to usability and accessibility, and it is specific rather than aspirational:
- Identity systems should be designed with Section 508 accessibility in mind and should account for mobility, dexterity, vision, hearing, and cognitive differences across the user base, not just the median user.
- Password and code entry fields should show the characters being typed by default rather than masking them, since masked entry increases error rates.
- Systems should allow at least 10 attempts at entering a code before lockout, with clear feedback on remaining attempts.
- Biometric authentication must always have a non-biometric alternative. A user should never be forced into a biometric method with no other option.
- Touch targets on mobile interfaces should be large enough for users with dexterity limitations, and help or recovery options should be easy to find, not buried in a settings menu.
Read together, the HIPAA standard sets the requirement (verify identity) and NIST's guidance sets a practical, testable bar for doing it in a way that does not exclude older users. A portal that offers only a single rigid MFA path is behind current guidance even if it technically satisfies HIPAA's authentication standard.
Authentication Methods Worth Evaluating, With Their Real Tradeoffs
There is no single authentication method that works for every patient population. The practical answer is usually to offer two or three options and let the patient, or their authorized caregiver, choose.
- Authenticator app with a generous code window. More phishing-resistant than SMS, but requires app installation and setup help the first time. Pair it with clear, illustrated setup instructions rather than text-only steps.
- Passkeys (FIDO2/WebAuthn). Device-bound passkeys meet the strongest assurance levels and remove the need to type or remember a code at all, since the device itself handles verification. The tradeoff is that patients need a modern device and some initial setup, so this works best as one option in a menu, not the only one.
- Voice-guided or extended-timeout OTP delivery. For patients without smartphones, a voice call with a code read aloud twice, combined with a longer validity window, is more usable than a text message that must be read and transcribed quickly.
- Biometrics with a mandatory fallback. Useful when it works, but only when paired with a non-biometric alternative that is equally easy to find, consistent with NIST's guidance above.
- Hardware security keys. Strong and phishing-resistant, but a poor default for a general patient population because of cost and the risk of a lost physical key. Better suited to staff accounts than patient-facing portals.
- Delegated or proxy access for caregivers. Many older patients rely on an adult child or caregiver to manage portal tasks. A formal, auditable proxy access feature, with its own verified identity and its own audit trail, is safer than a shared password, and it directly supports the patient portal security requirements covered entities already need to meet.
The common thread is choice plus a verified fallback, not a single "accessible" method substituted for a secure one.
The Section 1557 Accessibility Requirement Most Teams Are Not Tracking Yet
Authentication accessibility is no longer only a usability nice-to-have for healthcare organizations covered by Section 1557 of the Affordable Care Act. The Department of Health and Human Services' 2024 final rule implementing Section 1557 adopted the WCAG 2.1 Level AA standard as the technical benchmark for covered entities' websites and mobile applications, with compliance deadlines staggered by organization size. That rule applies to the entities Section 1557 already covers (most providers and plans that receive federal financial assistance), and a patient portal's login screen is squarely within its scope as a core piece of a covered entity's digital front door.
This is a useful forcing function even for organizations outside Section 1557's direct reach, because WCAG 2.1 AA is also the standard the Department of Justice applies to state and local government web content under its Title II rule, and it has become the de facto reference point across healthcare digital accessibility generally. For a login flow specifically, the practical implications are concrete: sufficient color contrast on code entry fields, keyboard and screen-reader navigability through every MFA step (not just the main page), error messages that are announced to assistive technology rather than only shown visually, and no reliance on a CAPTCHA or timing mechanism that cannot be adjusted or bypassed accessibly.
Whether or not a specific organization falls under the 2024 rule, treating the login flow as a compliance surface, not just the content pages around it, is the direction both accessibility law and authentication guidance are moving. This is informational context, not legal advice: whether a given rule applies and what it requires for a specific organization depends on its structure, funding, and legal counsel's reading of current guidance.
Practical Recommendations for the Login Flow Itself
Most of the fixes here are interface and policy decisions, not infrastructure rebuilds:
- Offer at least two authentication methods from the list above, so a patient is never dependent on the one that happens not to work for them.
- Lengthen code validity windows where the risk analysis supports it, rather than defaulting to the shortest interval a library ships with.
- Write setup and error messages in plain language, avoiding security jargon like "authenticator" or "token" without a one-line explanation the first time it appears.
- Build a real human fallback, meaning a phone-based help path, not only a self-service reset form, for patients who get stuck during setup.
- Test with actual older users, not just internal QA, before shipping changes to the login flow. Usability problems in authentication rarely show up in a standard test matrix.
- Log and review lockout and failed-login patterns by method, which tells you empirically which authentication option is failing a specific patient segment, feeding directly into the kind of audit logging HIPAA's technical safeguards already expect you to maintain.
None of this requires choosing a weaker overall security posture. It requires treating usability data about your actual patient population as part of the risk analysis, the same way you would treat a vulnerability scan.
Frequently Asked Questions
Does HIPAA require multi-factor authentication for patient portals?
Not explicitly. HIPAA's person or entity authentication standard requires a procedure that reliably verifies identity, decided through the organization's own risk analysis. MFA is widely used because it is an effective way to meet that standard, not because the regulation names it directly.
Can a patient portal legally offer a lower-security option for elderly patients?
Accessibility and security are not supposed to trade against each other under current guidance. The better approach is offering multiple verified authentication paths, including ones that are easier for older patients to use, rather than lowering the verification bar for any single group.
Are passkeys a good fit for older patient populations?
They can be, especially for patients with a modern smartphone, because they remove manual code entry entirely. They should be offered as one option among several rather than the only one, since initial setup still requires some comfort with the device.
What should a portal do for patients who do not have a smartphone?
Voice-delivered codes with extended validity windows, authenticator options tied to a landline where supported, or a formal caregiver proxy access feature are more realistic paths than assuming every patient can receive and read an SMS code quickly.
Does the Section 1557 accessibility rule apply to every healthcare organization?
It applies to entities covered by Section 1557, generally those receiving federal financial assistance connected to health programs. Coverage and compliance deadlines depend on organization size and structure, so this is general information rather than a determination for any specific organization; confirm applicability with legal counsel.
Authentication is one of the few places in a patient portal where a security control and a usability failure are the same screen. Getting it right for older patients, and for the caregivers who often help them, is less about picking a single "best" method and more about building a menu of verified options with a human fallback that actually works. If your team is evaluating a patient portal build or a login flow redesign and wants a second set of eyes on where accessibility and HIPAA's technical safeguards intersect, book a strategy call or see how our healthcare software development and accessible interface design work fits into a project like this.