How should healthcare organisations govern SMART on FHIR access?

Why This Matters for Security Teams

SMART on FHIR makes healthcare interoperability more usable, but it also turns every app, token, and integration path into a governance decision. If access is approved only at onboarding and never re-evaluated, a small scheduling or patient-facing app can accumulate broad API reach that outlives its original purpose. Current guidance suggests treating these integrations as non-human identities, not as temporary technical plumbing, because the risk sits in the credential and entitlement lifecycle.

That framing matters because healthcare environments often mix EHR integrations, third-party apps, service accounts, and delegated user access. Without clear ownership, minimum scope, and revocation paths, interoperability can quietly defeat least privilege. The NIST Cybersecurity Framework 2.0 emphasises governance, access control, and continuous risk management, which fits SMART on FHIR better than one-time approval models. NHI governance is also central to the Top 10 NHI Issues, especially where excessive privilege and weak lifecycle controls create avoidable exposure.

One relevant benchmark is that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to NHI Mgmt Group’s Ultimate Guide to NHIs. In practice, many security teams encounter overbroad SMART on FHIR access only after an app has already been reused beyond its original clinical purpose.

How It Works in Practice

Governance should start with inventory and classification. Each SMART on FHIR application should have a named business owner, a technical owner, an approved use case, and a documented data scope. Access should then be mapped to the smallest set of FHIR resources and operations needed for that use case. For example, a read-only patient engagement app should not also receive write permissions, bulk export access, or broader token scopes just because the platform can support them.

Operationally, teams should enforce short-lived credentials, token scoping, and revocation workflows that are tested, not just documented. The best pattern is to align onboarding and review to lifecycle controls described in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, then tie those controls to audit evidence. The OWASP Non-Human Identity Top 10 is useful here because it highlights common failures such as weak secrets handling, excessive permissions, and poor lifecycle hygiene.

• Assign each SMART on FHIR app an owner and a reviewed purpose statement.
• Issue only the minimum OAuth scopes needed for the clinical workflow.
• Use short token lifetimes and require re-authorization for changed use cases.
• Separate sandbox, staging, and production identities and do not reuse credentials across them.
• Log every token issuance, scope change, and revocation event for audit and incident response.

Where this guidance breaks down most often is in large health ecosystems with multiple vendors and delegated patient access, because scope creep and integration sprawl make it difficult to prove what each token can do at any given moment.

Common Variations and Edge Cases

Tighter access control often increases integration overhead, requiring organisations to balance interoperability speed against clinical safety and auditability. That tradeoff is real in healthcare, especially when external app developers need rapid access for testing, patient onboarding, or cross-system workflows. Best practice is evolving, and there is no universal standard for every implementation pattern yet, so governance has to be practical rather than rigid.

One common edge case is delegated access through patient-authorized apps. Those apps may legitimately access broad datasets on behalf of a patient, but that does not remove the need for identity ownership, app registration, and revocation. Another edge case is machine-to-machine access for back-end services, where the service account may need broader technical reach than a user-facing app, yet still requires explicit scope review and periodic recertification. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is helpful for turning those decisions into evidence that auditors can follow.

Healthcare organisations should also watch for third-party apps that request access once and remain connected indefinitely. The 80% of identity breaches involving compromised non-human identities, cited in 52 NHI Breaches Analysis, is a strong reminder that unmanaged tokens become durable attack paths. Where data-sharing agreements, clinical research integrations, or regional health information exchange models are involved, governance must be reviewed alongside legal and operational controls, not after deployment. For broader control mapping, the NIST Cybersecurity Framework 2.0 remains the most defensible baseline, while OWASP Non-Human Identity Top 10 helps teams focus on the most common failure modes.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern access from unmanaged endpoints?
• Should organisations allow contractors to access sensitive systems from personal devices?