Key takeaways
- FHIR (Fast Healthcare Interoperability Resources), HL7's standard for exchanging healthcare data via RESTful APIs, is deliberately silent on security mechanics.
- Because "OAuth is running" and "patient data is actually protected" turned out to be different claims when someone tested it against real systems.
- FHIR API security moved from "recommended practice" to "federally mandated, with named standards and a fixed deadline" over 2024–2027.
- Implement SMART App Launch, not a bespoke OAuth variant — both the user-facing flow and, for system integrations, Backend Services with JWT-assertion client authentication rather than a long-lived shared secret.
HL7's FHIR specification says directly that it is not a security protocol: it defines data models and exchange patterns, and recommends pairing them with OAuth 2.0, SMART App Launch, OpenID Connect and TLS — but implementing and correctly enforcing those controls, especially per-record authorization, is left entirely to whoever builds the API. That gap is not theoretical: a 2021 test of production FHIR APIs found broken object-level authorization — one patient's session reaching another patient's records — in the majority of systems tested, despite OAuth already running in front of them. Two federal rules now turn FHIR API security from best practice into a hard 2026–2027 compliance deadline for anyone serving U.S. healthcare data.
What does FHIR actually secure, and what does it leave to implementers?
FHIR (Fast Healthcare Interoperability Resources), HL7's standard for exchanging healthcare data via RESTful APIs, is deliberately silent on security mechanics. The specification states it outright: FHIR is not a security protocol and does not define security-related functionality itself; instead it "define[s] exchange protocols and content models that need to be used with various security protocols defined elsewhere." What the spec does provide is a set of recommendations layered on top of that honest disclaimer — OAuth 2.0 for authorizing client access, OpenID Connect for authenticating end users in web-centric deployments, TLS per IETF BCP 195 for every production exchange, and an AuditEvent resource purpose-built to record security- or privacy-relevant events. None of these are optional extras the spec considers nice-to-have; they are its own recommended answer to "how do you secure this." But a recommendation is not an enforcement mechanism, and the spec says so directly: "It is the responsibility of implementers to ensure that relevant regulations and other requirements are met." A server can conform fully to FHIR's resource models and RESTful API shape while implementing none of this — conformance testing checks what the data looks like on the wire, not whether the wire is locked down.
What does SMART App Launch require, and who actually needs which flow?
SMART App Launch is HL7's own implementation guide for wiring OAuth 2.0 to FHIR specifically, and it's the concrete standard both CMS and ONC now point to (below) rather than leaving "use OAuth" as an abstract recommendation. It splits into two patterns depending on who's connecting:
| SMART App Launch (user-facing) | SMART Backend Services (headless) | |
|---|---|---|
| Use case | Patient or clinician-facing app, launched standalone or from inside an EHR session | Automated system-to-system integration with no human present |
| Flow | OAuth 2.0 authorization-code grant, with user consent | OAuth 2.0 client-credentials grant |
| Client authentication | Confidential clients authenticate; public clients (e.g. mobile apps with no secure secret storage) may not | JWT assertion (RFC 7523), SMART's preferred method "because it avoids sending a shared secret over the wire" |
| PKCE | Required (S256) on the authorization-code request in the current STU 2.2 release | Not applicable — no browser redirect involved |
| Discovery | .well-known/smart-configuration relative to the FHIR server's base URL, in both cases |
Same |
Access granted through either flow is scoped — SMART describes this as "a language of 'scopes' to define specific access permissions that can be delegated to a client application" — but a scope only constrains what an app is allowed to ask for. Whether the server then checks that a specific request stays inside that scope, resource by resource, is the part FHIR leaves to the implementer, and it's exactly where the next section's research found the gap.
Why did independent research call FHIR APIs healthcare's "last mile" risk?
Because "OAuth is running" and "patient data is actually protected" turned out to be different claims when someone tested it against real systems. Alissa Knight's "Playing with FHIR" research, presented at DEF CON 29's Biohacking Village in 2021, tested production FHIR APIs from major EHR ecosystems and found vulnerabilities in 60% of the APIs examined. The headline finding, consistently reported across the tested systems, was Broken Object Level Authorization (BOLA): an attacker authenticated with one patient's own valid credentials could reach other patients' records, because the server verified who was calling without separately verifying which specific records that caller was entitled to retrieve. The mobile-app side of the research was similarly blunt: 53% of the tested apps had hard-coded API keys or tokens embedded directly in the client, and none of the tested apps used certificate pinning — meaning an attacker positioned on the network path could intercept and manipulate traffic between the app and the API with a basic machine-in-the-middle setup. HL7's own response to the research is worth taking at face value rather than dismissing: it attributed the vulnerabilities to "the implementation of apps and by third-party FHIR aggregators," not the FHIR standard — which lines up exactly with what FHIR's own security page already says about scope. The standard was never going to catch this for you; something downstream has to.
What do CMS and ONC now require, and by when?
FHIR API security moved from "recommended practice" to "federally mandated, with named standards and a fixed deadline" over 2024–2027. Two rules matter here:
ONC's HTI-1 final rule (effective 11 March 2024) tightens the certification criteria health IT modules must meet to keep their §170.315(g)(10) FHIR API certification. Two provisions matter most for security: certified modules must be able to "revoke an authorized application's access at a patient's direction within one hour of the request," effective from the rule's effective date; and certified developers must move from the SMART App Launch v1 implementation guide to v2.0.0, with v1 no longer accepted for new certification after 31 December 2025. This guide draws its HTI-1 provisions from HealthIT.gov's own overview fact sheet; the underlying PDF did not render cleanly through this review's tooling, so treat the dates above as the publicly reported provisions rather than a line-by-line reproduction of the regulatory text.
CMS's Interoperability and Prior Authorization final rule (CMS-0057-F), published 17 January 2024, is more prescriptive still. It requires impacted Medicare Advantage, Medicaid, CHIP and qualified health plan payers to implement four FHIR-based APIs — Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization — each required "beginning January 1, 2027," with Patient Access API usage-metrics reporting to CMS starting a year earlier on 1 January 2026. CMS's own fact sheet names the authorization standard explicitly rather than leaving it generic: "OpenID Connect Core 1.0" together with the "HL7 SMART Application Launch Framework Implementation Guide Release 1.0.0." A payer that exposes FHIR-shaped endpoints without implementing those specific named standards has not met the rule, regardless of whether the data itself is correctly modeled.
Checklist for device makers and health IT vendors building a FHIR API
Implement SMART App Launch, not a bespoke OAuth variant— both the user-facing flow and, for system integrations, Backend Services with JWT-assertion client authentication rather than a long-lived shared secret. Enforce object-level authorization on every read and write, tied to the authenticated caller's actual patient/provider relationship — this is the exact control FHIR's own spec leaves to implementers, and the one "Playing with FHIR" found missing across most of the APIs it tested. Require TLS per BCP 195 everywhere, with no plaintext fallback path, and populate the AuditEvent resource for security-relevant access so an incident is actually investigable afterward. For patient-facing mobile apps: add certificate pinning and eliminate hard-coded API keys/tokens from the client binary — the two specific, documented gaps found in the majority of apps tested in 2021. If covered by CMS-0057-F or ONC certification, confirm you've implemented the specifically named standards (SMART App Launch v2, OpenID Connect Core 1.0, one-hour patient-directed revocation) ahead of the 1 January 2027 and 31 December 2025 deadlines, not a functionally similar but differently specified flow. Treat the FHIR server as one component of the shipped product's attack surface, not a security boundary on its own — the access tokens, client secrets and TLS configuration it depends on live in firmware, mobile app binaries and backend services that each need their own security review.
This guide draws on HL7's own published FHIR and SMART App Launch specifications, the Approov/Knight Ink "Playing with FHIR" research and its public reporting, and CMS's and ONC's own fact sheets on CMS-0057-F and HTI-1; the full CMS-0057-F and HTI-1 regulatory PDFs did not render cleanly through this review's tooling, so granular rule text is represented via each agency's own fact-sheet summary rather than a clause-by-clause reading of the Federal Register text. This guide is general information, not legal or regulatory advice for a specific submission.
Sources
- HL7 FHIR: Security (core specification page — "FHIR is not a security protocol")
- HL7 FHIR: SMART App Launch Implementation Guide
- Approov / Knight Ink: Hacking and Securing FHIR API Implementations ("Playing with FHIR")
- CMS: Fact Sheet — CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
- ONC / HealthIT.gov: HTI-1 Final Rule overview fact sheet (PDF)
Frequently asked questions
Is HL7 FHIR itself a secure protocol, or does it leave security to implementers?
FHIR itself is explicit that it isn't. HL7's own FHIR specification states plainly: 'FHIR is not a security protocol, nor does it define any security related functionality,' and that implementers must instead pair FHIR's exchange protocols and content models 'with various security protocols defined elsewhere.' The spec recommends specific building blocks — OAuth 2.0 for authorization, OpenID Connect for user authentication in web-centric settings, TLS per IETF BCP 195 for transport, and an AuditEvent resource for logging — but recommending a building block is not the same as mandating or implementing one. The specification says directly: 'It is the responsibility of implementers to ensure that relevant regulations and other requirements are met.' A FHIR server can be fully conformant to the base specification while having no authentication at all; conformance testing checks data models and exchange semantics, not whether a deployment is actually locked down.
What does SMART App Launch actually require for authorizing an app against a FHIR API?
SMART App Launch is HL7's own implementation guide for applying OAuth 2.0 to FHIR, and it is the piece CMS and ONC now point to as the required security standard (see below). It defines two patterns: SMART App Launch proper, which 'authorizes a user-facing client application ("App") to connect to a FHIR Server' through a browser-based OAuth 2.0 authorization-code flow with user consent, and SMART Backend Services, which 'authorizes a headless or automated client application ("Backend Service") to connect to a FHIR Server' using the OAuth 2.0 client-credentials grant with a JWT assertion as the client's authentication — built on RFC 7523's JWT profile rather than a shared secret. The current release (STU 2.2) also mandates PKCE with S256 on authorization-code requests, and exposes a standard discovery document at '.well-known/smart-configuration' relative to the server's FHIR base URL so a client can find the authorization and token endpoints without hard-coding them. Access itself is scoped: SMART's own language describes this as scopes that 'define specific access permissions that can be delegated to a client application' — but which scopes a given user or app actually receives, and whether the server enforces them correctly per resource, is implementation-specific.
Why did a 2021 security research project call FHIR APIs healthcare's 'last mile' risk, if the standard already has an OAuth-based security framework?
Because having an OAuth framework available and having it correctly enforced per-patient are different claims, and Alissa Knight's 'Playing with FHIR' research (presented at DEF CON 29's Biohacking Village, sponsored by Approov) tested that gap directly against production systems. The published findings: 60% of the FHIR APIs tested contained vulnerabilities, 53% of the mobile apps tested shipped with hard-coded API keys or tokens embedded in the client, and none of the mobile apps tested used certificate pinning, leaving them open to credential-harvesting machine-in-the-middle attacks. Reporting on the research described the core failure as Broken Object Level Authorization across the production APIs tested — an authenticated app could reach records belonging to patients other than the one who had logged in, meaning OAuth correctly verified who the caller was without the server separately verifying which specific records that caller was entitled to see. HL7 responded that the vulnerabilities Knight found 'lie with the implementation of apps and by third-party FHIR aggregators' rather than with the FHIR standard itself — which is consistent with what FHIR's own security page says about scope: the spec was never going to enforce that check for you.
What do CMS and ONC now require for FHIR API security, and by when?
Two federal rules now turn what used to be "recommended" FHIR security practice into a certification and payer requirement, on a firm 2026-2027 timeline. ONC's HTI-1 final rule (effective 11 March 2024) requires health IT certified for the FHIR API criterion (§170.315(g)(10)) to be able to 'revoke an authorized application's access at a patient's direction within one hour of the request' — a deadline that took effect on the rule's effective date — and separately moves certified developers from the SMART App Launch Implementation Guide v1 to v2.0.0, with the v1 guide no longer accepted after 31 December 2025. CMS's Interoperability and Prior Authorization final rule (CMS-0057-F, published 17 January 2024) goes further on the payer side: it requires impacted Medicare Advantage, Medicaid, CHIP and qualified health plan issuers to stand up four FHIR-based APIs — Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization — each required to be implemented by 1 January 2027 (with usage-metrics reporting for the Patient Access API starting a year earlier, 1 January 2026), and the rule names its security standard explicitly: 'OpenID Connect Core 1.0' together with the 'HL7 SMART Application Launch Framework Implementation Guide Release 1.0.0' for authorization. A payer that stands up a FHIR API without actually implementing those named standards is not meeting the rule, regardless of whether the API otherwise returns FHIR-shaped data.
Does using FHIR plus OAuth automatically stop the kind of broken-authorization problem the research found?
No, and this is the single most important distinction in FHIR API security. OAuth 2.0 and SMART App Launch answer 'is this a legitimate app, acting for this authenticated user, with these granted scopes?' — they do not answer 'should this specific request be allowed to read this specific patient's specific record?' That second check is object-level authorization, and FHIR's own specification does not supply it: the spec notes that FHIR 'readily enables RBAC' and 'readily enables ABAC' as general access-control models a server could implement, but building and correctly enforcing the actual per-resource rule — checking a resource's owning patient ID against the authenticated caller's granted context on every single read, not just at login — is server-side application logic FHIR does not provide out of the box. 'Playing with FHIR' found this exact gap in production: APIs that had working OAuth in front of them but no equivalent check behind it, letting one patient's valid session reach another patient's records.
What should a device maker or health IT vendor building a FHIR API actually verify before launch?
Treat FHIR's own framing as the checklist: the protocol gives you the data model and the recommended building blocks, and your implementation is responsible for everything that makes those blocks actually hold. Concretely: implement SMART App Launch (not a bespoke OAuth variant) so clients can rely on standard discovery and scopes; use the Backend Services JWT-assertion flow rather than a long-lived shared secret for any system-to-system integration; enforce TLS per BCP 195 on every endpoint, with no plaintext fallback; add an explicit per-resource authorization check — tied to the authenticated subject's actual patient/provider relationship, not just their authenticated identity — on every read and write, since this is the control FHIR's own spec leaves to you and the exact one 'Playing with FHIR' found missing; populate the AuditEvent resource for security-relevant access so an incident is actually investigable after the fact; and if the API serves a patient-facing mobile app, add certificate pinning and avoid hard-coding API keys or tokens in the client binary, the two specific gaps the 2021 research found in the majority of apps it tested. If the API falls under CMS-0057-F or ONC certification, confirm the specific named standards (SMART App Launch v2, OpenID Connect Core 1.0, one-hour revocation) are implemented, not just "an OAuth flow that works."
In this cluster
