HL7's own security page says FHIR "is not a security protocol, nor does it define any security related functionality." A FHIR server is not secure by default. You add transport encryption, authentication, authorization, audit, consent handling and input validation, using standards the page recommends.
What the specification does and does not do
FHIR defines exchange protocols and content models intended to work with security protocols defined elsewhere. It has no user administration resources. The security labels mechanism is the closest thing to built in access control, and labels only describe data. Something else has to act on them.
The page also puts responsibility on implementers: you must meet the regulations that apply to you, and data sensitivity depends on context. It names HIPAA and GDPR as examples.
The checklist the page implies
Transport
- Use TLS for production data. The page points to IETF BCP 195 for configuration.
- Keep clocks synchronized with NTP or SNTP, and tolerate a wrong clock value.
- Use CORS for browser based clients.
Identity and access
- Authenticate users and clients.
- Use OAuth for web centric use, with OpenID Connect where end user identity is needed. The SMART App Launch guide is described as a recommended way to apply OAuth to a protected FHIR server. See SMART on FHIR scopes explained.
- Consider UDAP and tiered OAuth to scale trust between organizations.
- Pick an access model. The page describes role based and attribute based access control as models FHIR supports.
Data protection
- Treat HTTP logs, even URL only logs, as sensitive as the resources themselves.
- Handle attachments with care, since they can carry executable content.
- Validate all input from other actors and test against fuzzing and injection attacks.
Accountability
- Use AuditEvent and Provenance resources to track origin, authorship, history, status and access.
- Consider legal and ethical duties to report security and privacy events.
Small details that matter
The page notes that FHIR narrative cannot contain active content, but software that displays it still needs care with external references and cookies. It also covers digital signatures, where FHIR reserves locations for them.
Another subtle point: the log guidance. Many teams scrub request bodies from logs and forget that a URL like a patient search can disclose identifiers. Treat URLs as data.
Where teams go wrong
- Standing up an open test server and promoting it to production with the same configuration.
- Assuming a gateway handles authorization when scopes are never checked against the resource requested.
- Skipping audit because it is "optional" in the spec.
None of these are FHIR flaws. The spec leaves them to you.
Quick check
Does using SMART on FHIR make my server secure?
SMART gives you a well defined OAuth based authorization flow. You still need TLS, correct scope enforcement, audit, input validation and a policy for consent and sensitive data.
Are security labels enforced by the server automatically?
No. Labels describe handling needs. Enforcement must come from your access control layer.
Sources
Last reviewed: 19 October 2026.
