Zero-Trust Architecture for Health Records: Lessons from Banking

The Perimeter Is Dead. Healthcare Hasn't Noticed.

In January 2020, the Office of the Comptroller of the Currency — the agency that regulates national banks in the United States — published an updated handbook on information security. Buried in its 134 pages was a sentence that captured three decades of hard lessons from the financial sector: "Institutions should not rely on perimeter controls as a primary security mechanism."

The banking industry didn't arrive at this position voluntarily. It arrived there through catastrophic failures. The 2014 JPMorgan Chase breach exposed data on 76 million households — the attackers bypassed perimeter defenses entirely by compromising a single employee's credentials. The 2016 Bangladesh Bank heist moved $81 million through SWIFT using stolen authentication tokens that the perimeter couldn't distinguish from legitimate requests. The 2019 Capital One breach exploited a misconfigured web application firewall to access 100 million customer records stored in AWS — the data was inside the perimeter, and the perimeter was irrelevant.

Each failure taught the same lesson: the castle-and-moat model — hard exterior, soft interior — doesn't work when the moat has bridges, the walls have gaps, and the attackers are already inside.

The financial sector's response was zero trust. Not as a product, not as a feature, but as an architectural principle: never trust, always verify. Every request is authenticated. Every access is authorized at the resource level. No entity — user, device, application, or service — receives implicit trust based on network location. The principle was formalized by NIST in Special Publication 800-207 (2020) and is now the default security architecture for every major financial institution globally.

Healthcare, meanwhile, is still building castles.

What Banking Learned That Healthcare Hasn't

The parallels between financial data and clinical data are closer than most technologists acknowledge. Both are high-value targets for attackers. Both are subject to rigorous regulatory frameworks (PCI DSS and SOX for finance; HIPAA and HITECH for healthcare). Both involve data that, if compromised, causes irreversible harm to individuals. And both industries operate complex, multi-party ecosystems where data must flow between institutions — banks to clearinghouses to regulators; hospitals to labs to insurers to pharmacies.

But the financial sector is fifteen years ahead of healthcare in one critical respect: it stopped trusting its own network a long time ago. Here are the three principles banking adopted that healthcare still resists.

Principle 1: Identity Is the New Perimeter

In a traditional healthcare architecture, a clinician who logs into the EHR has broad access to patient records. A single session token, often valid for hours, grants access across the system. The assumption: if you're inside the network and authenticated, you belong here.

Banking abandoned this assumption after the SWIFT network attacks. Modern banking systems verify identity at every transaction — not just at login. A wire transfer request triggers re-authentication. Accessing a different customer's account requires role verification. A trade execution at 3 AM from an unfamiliar IP triggers step-up authentication even if the session is valid. The principle: authentication at the gate is not authentication at the vault.

In a zero-trust health architecture, the same principle applies. Accessing a patient's lab results is a different authorization decision than accessing their medication list, even within the same clinical session. Viewing a record is different from modifying it. Downloading a record for referral purposes is different from viewing it on screen. Each action is a discrete authorization event, evaluated against the clinician's role, the patient's consent preferences, the data sensitivity level, and the access context (time, location, device).

Principle 2: Least Privilege Is Not Optional — It's Default

The principle of least privilege — granting only the minimum access needed for a specific task — has been a theoretical best practice in healthcare IT for decades. In practice, most EHR implementations grant role-based access that is far broader than any individual task requires. A nurse who needs to verify a medication list has read access to the entire patient chart. A billing specialist who needs diagnosis codes can see clinical notes, lab results, and provider assessments.

Financial services regulators enforce least privilege with teeth. The Gramm-Leach-Bliley Act's Safeguards Rule (updated 2023) requires financial institutions to implement access controls that limit data access to employees who need it for their "current, legitimate business purpose." The emphasis on current is deliberate — access that was appropriate yesterday may not be appropriate today if the employee's role or assignment has changed.

PCI DSS 4.0, released in March 2024, goes further: Requirement 7 mandates that access to cardholder data is restricted by "business need-to-know," and Requirement 7.2.5 requires that access privileges are reviewed at least every six months. The equivalent HIPAA standard — the Minimum Necessary Rule — articulates the same principle but enforces it with far less specificity. Most healthcare organizations interpret "minimum necessary" at the role level, not the transaction level.

Principle 3: Every Access Creates an Auditable Event

In banking, every access to customer financial data generates an audit record: who accessed what, when, from where, for what stated purpose, and what they did with it. These audit logs are immutable, retained for regulatory periods (typically 5-7 years), and subject to automated anomaly detection that flags unusual patterns — a teller accessing accounts outside their branch, a trader viewing positions they're not assigned to, an administrator downloading bulk customer data.

HIPAA requires audit controls (§164.312(b)), but the regulation provides minimal guidance on what constitutes an adequate audit trail. Many healthcare organizations log access at the session level (user X logged into the EHR at time Y) rather than at the resource level (user X accessed patient Z's lab results at time Y and viewed them for 45 seconds). The difference is the difference between knowing someone entered the building and knowing which rooms they visited, which drawers they opened, and which documents they read.

A 2023 Ponemon Institute study on healthcare cybersecurity found that organizations with resource-level audit logging detected breaches an average of 74 days faster than those with session-level logging alone. Seventy-four days of undetected data exfiltration is not a minor operational gap — it's the difference between a contained incident and a catastrophic breach.

"In banking, the question is never 'did someone access the data?' The question is always 'did the right person access the right data, for the right reason, at the right time, and can we prove it?' Healthcare doesn't ask this question yet. It will have to."

Translating Zero Trust to FHIR-Native Infrastructure

Adopting zero-trust principles in healthcare isn't a matter of bolting banking security products onto existing EHR infrastructure. Healthcare data has unique characteristics — consent-driven access, clinical urgency overrides, multi-provider shared records — that require purpose-built implementation. Here's how we translated each banking principle into our FHIR R5-native platform at LivoRx.

Resource-Level Authorization with SMART on FHIR

FHIR's resource model — where clinical data is organized into discrete, typed resources (Patient, Observation, MedicationRequest, DiagnosticReport, etc.) — is inherently suited to granular authorization. Each FHIR resource has a defined scope, a defined sensitivity profile, and a defined set of operations (read, write, search, delete).

We implement authorization using the SMART on FHIR framework (Substitutable Medical Applications, Reusable Technologies), which extends OAuth 2.0 with healthcare-specific scopes. A clinician's access token doesn't grant access to "the patient's record" — it grants access to specific resource types with specific operations. A token scoped to patient/Observation.read allows reading lab results but not modifying them. A token scoped to patient/MedicationRequest.write allows prescribing but not viewing diagnostic reports.

Scopes are composed dynamically based on three factors: the clinician's role (physician, nurse, pharmacist, billing), the care relationship (is this clinician on this patient's care team?), and the patient's consent directives (has the patient restricted access to sensitive categories like behavioral health or reproductive health?). The authorization decision is made at every API call — not once at login. This is the FHIR equivalent of banking's per-transaction verification.

Patient Consent as Enforceable Policy

In banking, customers can restrict who sees their financial data — placing holds on information sharing, opting out of marketing data use, flagging accounts for enhanced privacy. These preferences are encoded as system policies, not as notes for human review.

We implement the same pattern using FHIR's Consent resource. A patient's privacy preferences — which providers can see their records, which data categories are restricted, whether AI systems can process their clinical text — are encoded as machine-readable policy objects that the authorization engine evaluates at every access request. The consent isn't advisory. It's enforced at the API layer. If a patient has restricted access to their behavioral health records, the authorization engine filters those resources from the response — the requesting clinician never sees them, doesn't know they exist, and can't discover them through search.

This approach aligns with the 21st Century Cures Act's information blocking provisions while respecting patient autonomy: data flows freely to authorized recipients, but patient-directed restrictions are computationally enforced, not administratively managed. The HL7 FHIR Consent resource (R5) provides the data model; our authorization engine provides the enforcement.

Microsegmentation: Isolating Clinical Data Domains

In banking, different data classes live in different security zones. Customer identity data, transaction records, credit scoring models, and regulatory reports are each isolated in separate network segments with independent access controls. A compromise in one segment doesn't cascade to others. This is microsegmentation — a zero-trust principle that treats the internal network as untrusted territory.

We apply the same architecture to clinical data domains. Patient demographic data (FHIR Patient, RelatedPerson resources), clinical observations (Observation, DiagnosticReport), care plans (CarePlan, ServiceRequest), and financial/billing data (Claim, Coverage) each reside in isolated data segments with independent encryption keys, independent access policies, and independent audit streams. A compromised service that processes lab results cannot access billing records. A vulnerability in the scheduling system cannot reach clinical notes.

Each segment communicates through authenticated, encrypted service-to-service channels using mutual TLS (mTLS) — the same protocol banks use for inter-service communication within their payment processing networks. No internal service trusts another service by default. Every service-to-service request presents a certificate, which is validated against a certificate authority that we operate, not a shared secret that could be compromised.

The Break-Glass Problem: When Zero Trust Meets Clinical Urgency

Here's where healthcare diverges from banking — and where naive application of financial security models breaks down.

In banking, if a transaction is blocked by security controls, the worst case is a delayed payment. In healthcare, if a security control blocks access to a patient's allergy list during an emergency, the worst case is a fatal medication error. Clinical urgency creates a category of access requirement that has no parallel in financial services: the need to override normal authorization controls when a patient's life is at risk.

This is the "break-glass" problem, and it's the reason many healthcare security teams resist zero trust. Their concern is legitimate: a system so locked down that clinicians can't access critical information in emergencies is worse than a system with broader access controls.

Our solution borrows from both healthcare and banking. We implement a tiered emergency access model:

1. Standard access: All authorization rules enforced. Consent directives respected. Scopes validated per-request. This covers >99% of all clinical interactions.
2. Urgent access: When a clinician declares clinical urgency (a single button in the interface, not a lengthy form), scope restrictions are temporarily broadened to include all clinical resources for the specified patient. The access is logged with an urgency flag, and a mandatory post-access justification is required within 24 hours. This is reviewed by the compliance team.
3. Emergency access: In true emergencies (patient unresponsive, identity unknown), a designated emergency credential grants read access to any patient record without prior authorization. Every millisecond of access is logged. An automatic review is triggered. The clinician must provide written justification within 4 hours.

The critical insight from banking: break-glass access doesn't weaken zero trust — it strengthens it, because it provides a legitimate, audited path for exceptional access instead of encouraging workarounds (shared passwords, propped-open doors, always-on session tokens) that undermine the entire model. JPMorgan's security architecture includes similar tiered override mechanisms for trade-floor emergencies. The override is part of the design, not a circumvention of it.

Immutable Audit Trails: Borrowing from SOX Compliance

The Sarbanes-Oxley Act of 2002 (SOX) was passed in the wake of the Enron and WorldCom scandals. Among its provisions: financial institutions must maintain audit trails that are complete, tamper-evident, and retained for defined periods. Destroying or altering audit records is a federal crime carrying up to 20 years imprisonment (18 U.S.C. § 1519).

Healthcare has no equivalent enforcement for audit trail integrity. HIPAA requires audit controls, but doesn't specify that audit logs must be immutable. In many healthcare organizations, audit logs are stored in the same database as the clinical data — meaning an attacker who compromises the database can alter the audit trail to cover their tracks. This is the equivalent of a bank letting the person who robbed the vault also edit the security camera footage.

We implemented banking-grade audit infrastructure using append-only, cryptographically chained log storage. Each audit event is hashed and linked to the previous event in a chain (conceptually similar to blockchain, but using a simpler Merkle tree structure that doesn't require consensus mechanisms). Altering any event in the chain invalidates all subsequent hashes, making tampering computationally detectable. The audit store is physically separated from the clinical data store, with independent encryption keys, independent backup infrastructure, and independent access controls.

Every FHIR resource interaction generates an audit event conforming to the IHE ATNA (Audit Trail and Node Authentication) profile — the healthcare interoperability standard for audit logging. The event captures: the requesting user's identity, their role, the patient whose data was accessed, the specific resource type and ID, the operation performed, the authorization decision (granted/denied), the scopes used, the source IP and device fingerprint, and the timestamp with millisecond precision.

These audit trails serve three purposes simultaneously: HIPAA compliance (demonstrating that access controls are implemented and monitored), breach detection (automated anomaly detection flags unusual access patterns within hours rather than months), and forensic investigation (when a breach does occur, the immutable audit trail provides legally defensible evidence of exactly what happened).

Encryption Lessons: From PCI DSS to FHIR Resources

PCI DSS has required encryption of cardholder data at rest since version 1.0 (2004). The standard is specific: AES-256 or equivalent, with encryption keys managed separately from the data they protect (Requirement 3.5), rotated at defined intervals (Requirement 3.6), and stored in hardware security modules for the highest sensitivity levels.

HIPAA's encryption provisions, by contrast, are "addressable" rather than "required" — an implementation specification that organizations can satisfy by documenting why encryption isn't necessary rather than actually implementing it. The 2024 HHS NPRM (Notice of Proposed Rulemaking) for HIPAA Security Rule modernization proposes making encryption of ePHI at rest a required specification — twenty years after banking made the same transition.

Our FHIR resource storage implements field-level encryption that goes beyond full-database encryption. Patient identifiers (name, DOB, SSN, MRN) are encrypted with dedicated keys separate from the keys that encrypt clinical content (observations, diagnoses, medications). This means a compromise of the clinical data encryption key doesn't expose patient identities, and vice versa. The architecture mirrors how banking separates authentication credentials from financial records — different keys, different access paths, different blast radius.

Key management follows the NIST 800-57 key management lifecycle: generation using FIPS 140-2 validated cryptographic modules, distribution via a dedicated key management service (not embedded in application code), rotation every 90 days for data encryption keys and annually for key-encrypting keys, and secure destruction with cryptographic erasure when keys are retired.

Continuous Verification: Behavioral Analytics from Fraud Detection

The most sophisticated element of banking's zero-trust implementation isn't authentication or encryption — it's behavioral analytics. Banks don't just verify that you are who you claim to be; they continuously verify that you're behaving like who you claim to be.

If a bank customer who normally makes three transactions a day suddenly initiates fifty, the system flags it. If a trader who covers European equities starts querying Asian fixed-income positions, the system flags it. If an account manager who normally works 9-5 EST accesses systems at 2 AM from an IP address in a different country, the system flags it. These behavioral baselines are established per-user and per-role, and deviations trigger graduated responses from alerts to automatic session termination.

We apply the same principle to clinical data access. Each clinician on the platform has a behavioral profile that captures their normal access patterns: how many patient records they access per shift, which resource types they typically read, what times they're normally active, which devices they use. When a clinician's behavior deviates significantly from their baseline — accessing an unusually high number of records, viewing records for patients not on their schedule, accessing sensitive categories they don't normally touch — the system generates a graded alert.

This is not hypothetical. A 2022 investigation by ProPublica documented cases where healthcare workers accessed celebrity patient records, ex-partners' records, and neighbors' records out of curiosity rather than clinical need. These "snooping" incidents — technically HIPAA violations — are almost impossible to detect with traditional access controls because the user has legitimate credentials and a role that permits access. Only behavioral analytics can distinguish between a nurse who accesses 30 patient records during a busy shift (normal) and a nurse who accesses 30 patient records in a department they don't work in at 11 PM (anomalous).

What This Costs — and What It Saves

Zero-trust architecture is more expensive to build than perimeter security. This is true for banking and it's true for healthcare. The microsegmentation, the per-request authorization, the immutable audit infrastructure, the behavioral analytics — each layer adds engineering complexity and operational cost.

But the cost calculus changes when you consider what it prevents. IBM's 2024 Cost of a Data Breach Report found that organizations with mature zero-trust implementations experienced breach costs that were $1.76 million lower than those without zero trust — $3.12M versus $4.88M average. For healthcare specifically, where breach costs are the highest of any industry, the savings are proportionally larger.

More importantly, zero trust changes the blast radius of a breach. In a perimeter-secured system, a single compromised credential can expose the entire database — every patient, every record, every field. In a zero-trust architecture with microsegmentation and resource-level access controls, a compromised credential exposes only the data that credential was authorized to access during the window before detection. The difference is between losing everything and losing a bounded, identifiable subset — a subset that can be precisely identified through the immutable audit trail for targeted breach notification rather than the mass notifications that erode patient trust.

Why Healthcare Is Behind — and How to Close the Gap

If zero trust is so clearly superior, why hasn't healthcare adopted it? Three structural factors explain the lag:

1. Legacy EHR monoliths. Most hospital EHR systems are monolithic applications that predate modern security architecture. Implementing resource-level authorization in a system designed around session-based access requires either fundamental re-architecture (prohibitively expensive for existing installations) or middleware shims that add latency and complexity. New platforms — built FHIR-native from the ground up — don't carry this technical debt.
2. Regulatory ambiguity. HIPAA's security requirements are principles-based, not prescriptive. "Implement access controls" doesn't tell an organization whether to implement role-based, resource-based, or attribute-based access control. PCI DSS, by contrast, specifies exactly what controls are required, at what granularity, with what audit frequency. The proposed HIPAA Security Rule update (2024 NPRM) moves toward greater specificity, but it hasn't been finalized.
3. The clinical workflow constraint. Banking security can afford to add friction — a 2-second delay on a wire transfer is acceptable. Healthcare security cannot afford to add friction to clinical workflows — a 2-second delay when a physician needs a patient's allergy list during an adverse reaction is not acceptable. Zero-trust implementations in healthcare must be invisible to the clinician in normal operation, which requires significantly more engineering investment than banking's user-facing security prompts.

The gap is real, but it's closing. FHIR-native platforms that build zero trust into the foundation rather than retrofitting it onto legacy architecture can achieve banking-grade security without the clinical workflow penalties that legacy systems impose. The question for the industry is whether the transition happens proactively — driven by engineering conviction — or reactively, driven by the next catastrophic breach that finally forces regulatory action.

We built LivoRx on the assumption that it would be the former. But we designed our architecture to be ready for the latter.

References

• NIST Special Publication 800-207, "Zero Trust Architecture" (2020): The foundational framework defining zero-trust principles, logical components, and deployment models for federal systems.
• Office of the Comptroller of the Currency, "Information Security Handbook" (2020): OCC guidance for national banks on information security controls, including the deprecation of perimeter-centric models.
• IBM Security, Cost of a Data Breach Report (2024): Healthcare breach average $4.88M; organizations with zero-trust architecture saved $1.76M per breach vs. those without.
• Ponemon Institute, "Cyber Insecurity in Healthcare" (2023): Resource-level audit logging detected breaches 74 days faster than session-level logging.
• PCI Security Standards Council, PCI DSS v4.0 (March 2024): Requirement 7 (restrict access by business need-to-know), Requirement 3.5 (encryption key management), Requirement 10 (audit trail requirements).
• Gramm-Leach-Bliley Act, Safeguards Rule (Updated 2023, 16 CFR Part 314): Requirement for financial institutions to limit data access to current, legitimate business purpose.
• Sarbanes-Oxley Act (2002), 18 U.S.C. § 1519: Criminal penalties for destruction or alteration of audit records in financial institutions.
• HHS NPRM for HIPAA Security Rule Modernization (2024): Proposed changes including mandatory encryption of ePHI at rest and enhanced audit trail requirements.
• SMART on FHIR Authorization Framework, HL7 International: OAuth 2.0-based authorization standard for healthcare applications with resource-level scoping.
• IHE ATNA Profile (Audit Trail and Node Authentication): Healthcare interoperability standard for cross-enterprise audit logging and node authentication.
• NIST Special Publication 800-57, "Recommendation for Key Management" (2020): Key management lifecycle guidance used in both financial services and healthcare encryption implementations.
• ProPublica (2022): Investigation documenting healthcare worker "snooping" incidents — unauthorized access to patient records by credentialed employees.