The Perimeter Is Gone: Securing Data in the Age of AI

3. Why the Perimeter Model No Longer Holds

Most healthcare organizations that suffer major breaches have done what the perimeter model asks. They have completed HIPAA risk assessments, signed Business Associate Agreements, implemented access controls, and adopted cloud platforms with security certifications. The breaches happen anyway, because those controls protect systems, and the systems using the data still hold the authority to decrypt it.

3.1 What HIPAA Requires and What It Does Not

HIPAA's Security Rule requires covered entities and business associates to implement reasonable safeguards for electronic PHI (protected health information). The rule is intentionally flexible, allowing organizations to choose measures appropriate to their size and risk profile. That flexibility creates gaps (HHS, 45 CFR Part 164):

• HIPAA does not mandate end-to-end encryption. Encryption is classified as an “addressable” specification, meaning organizations can satisfy it by documenting why they chose not to encrypt and implementing an alternative measure.
• HIPAA allows broad administrative and service-account access to PHI. There is no requirement that access be cryptographically enforced or that decryption keys be separated from infrastructure credentials.
• HIPAA does not restrict decryption inside applications. Once data reaches an authorized system, it can exist in plaintext across memory, logs, caches, and temporary storage.
• HIPAA does not protect PHI after sharing beyond requiring a Business Associate Agreement, which is a contractual control, not a technical one. A BAA cannot prevent a third party from storing or mishandling plaintext data.
• HIPAA does not require tamper-evident, cryptographic audit trails. Organizations may rely on system logs that can be altered, deleted, or incomplete.

The result: an organization can pass a HIPAA audit and still have PHI sitting in plaintext across dozens of systems, vendor environments, and shared workflows. This is not a theoretical risk. It is the pattern behind the major breaches described in Section 2.

3.2 The Expanding Attack Surface

A modern healthcare organization may share PHI with EHR vendors, billing and coding platforms, clearinghouses, insurance payers, telehealth systems, analytics tools, AI platforms, cloud providers, Health Information Exchanges, and numerous consultants, auditors, and service providers. Each connection is a point where PHI may be decrypted, cached, logged, or exposed. A large hospital may work with hundreds to thousands of third-party vendors (Ponemon Institute).

HIPAA's framework of BAAs and organizational policies was not designed to enforce technical protections across this kind of sprawl.

4. Why Cloud Adoption Has Not Solved the Problem

Cloud platforms like AWS, Azure, and Google Cloud provide strong infrastructure security: physical data centers, hardware isolation, availability, and baseline compliance certifications. But cloud security operates under a shared responsibility model. The provider secures the infrastructure, the customer is responsible for securing the data, applications, and access controls running on that infrastructure (AWS Shared Responsibility Model; Azure Shared Responsibility).

This distinction is frequently misunderstood. Migrating to AWS does not mean PHI is encrypted end-to-end, that administrators cannot access plaintext data, or that policies travel with data after sharing. Cloud encryption at rest and in transit protects data while stored on disk and while moving over a network. Both protections end the moment an application processes the data.

Healthcare breaches most often result from credential compromise, misconfiguration, third-party attacks, insider threats, and ransomware (Verizon DBIR, 2024). In every one of these scenarios, the cloud infrastructure performs exactly as designed. The breach occurs because PHI is accessible at the application layer to anyone with sufficient credentials or access.

5. Why Traditional Encryption Falls Short

Encryption at rest protects data stored on disk, but it remains transparent to the systems that use it. When data is accessed, it is automatically decrypted for any authorized service or user. This means that any entity with sufficient access, including a compromised administrator, insider, or breached service, can still query and read sensitive records in plaintext. In practice, encryption at rest primarily addresses the risk of physical theft of storage media, a threat that has largely been reduced by modern cloud infrastructure.

Encryption in transit (TLS/SSL) secures data as it moves between systems, protecting it from interception over the network. However, data is decrypted at each endpoint along the path, including servers, load balancers, API gateways, and applications, before it is processed or forwarded. TLS protects the connection, not the data itself. Once inside the system boundary, sensitive information is exposed again at each processing point.

Consumer end-to-end encryption, the model used by Signal, protects messages between sender and recipient. But healthcare requires multi-party access across physicians, specialists, billing teams, payers, and labs. Access requirements change over time and must be revocable. Consumer E2EE does not support revocation after delivery, centralized audit trails, or policy-based access controls for time, device, role, or geography.

Healthcare needs an encryption model that provides genuine end-to-end protection while supporting the complex, multi-party, policy-driven workflows the industry requires.

5.1 Tokenization and De-Identification Are Not Data Security

Beyond traditional encryption approaches, many healthcare organizations rely on tokenization and de-identification to reduce risk when sharing data across systems and organizations.

Platforms such as Datavant enable data to be linked, analyzed, and exchanged without directly exposing patient identifiers. These approaches provide significant value, particularly in life sciences, research, and clinical trial environments where identity resolution and longitudinal analysis are required.

However, tokenization is not a substitute for data security.

Tokenization replaces sensitive fields with tokens while maintaining a mapping that allows the original data to be re-associated when needed. In practice, this means that either the original data exists in identifiable form within the system, or the tokenized data can be re-identified through controlled processes. At some point in the workflow, the data must be available in plaintext.

This creates several limitations:

• No protection at the point of use: Systems that process or analyze data often require access to original values, exposing PHI in memory, logs, or downstream applications.
• Re-identification pathways introduce risk: Any system capable of resolving tokens back to identity becomes a high-value target.
• Limited control across systems: Tokenization does not enforce cryptographic access controls across vendors, applications, or infrastructure.
• No persistent protection after sharing: Once data is re-identified or combined with other datasets, control is effectively lost.

Tokenization is highly effective for specific use cases, particularly in research and data collaboration where identity abstraction is required. It is not designed to enforce continuous protection of PHI across operational healthcare workflows.

Record-level encryption addresses a different problem. Instead of removing identifiers, it protects the data itself. PHI remains encrypted across storage, transit, processing, and sharing, and is only decrypted when explicitly authorized. There is no persistent plaintext exposure, no reliance on re-identification pathways, and no loss of control after data is shared. These approaches are complementary, not interchangeable. Tokenization enables data utility. Record-level encryption ensures data security.

Tokenization assumes that systems, users, and intermediaries can be trusted to handle sensitive data appropriately. Record-level encryption assumes that any system, user, or vendor may be compromised, and enforces protection accordingly.

6. What Record-Level Security Actually Means

Traditional security asks: “Is this system secure?” Record-level security asks: “Is this data secure, regardless of what system it is on?”

Record-level security is a fundamentally different architecture. Instead of building walls around data or locking the rooms where data is stored, record-level security locks the data itself. The protection travels with the data. It does not matter if the system is compromised, the administrator is malicious, or the vendor is breached. Without correct cryptographic authorization, the data is unreadable.

Effective record-level security for healthcare must encrypt data at the source before it touches any network or third-party system; maintain encryption across storage, transit, and sharing, with decryption limited to authorized use; prevent intermediary access to plaintext without explicit cryptographic authorization; enforce access policies that travel with the data across organizations; support revocable, dynamic access control even after sharing; provide tamper-evident audit trails with cryptographic integrity; integrate into existing workflows without requiring operational changes; and scale across providers, vendors, payers, and analytics platforms.

7. Record-Level Security as Zero Trust Architecture

The federal and enterprise cybersecurity conversation has moved decisively toward Zero Trust Architecture. NIST Special Publication 800-207 defines Zero Trust as an approach that assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location. CISA's Zero Trust Maturity Model identifies five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. Of these, the Data pillar is arguably the most important and the least mature across healthcare.

Most organizations pursuing Zero Trust focus on identity verification and network segmentation. These are necessary but incomplete. A Zero Trust architecture that does not protect the data itself leaves the most valuable asset unprotected. If an attacker bypasses identity controls, compromises credentials, or exploits a trusted insider's access, every record in plaintext is exposed.

Record-level encryption is the Zero Trust implementation healthcare requires. It enforces the principle that no entity, whether a user, service, application, or administrator, is trusted with access to plaintext data without explicit, cryptographic, policy-driven authorization at the point of decryption. This maps directly to the most advanced tier of CISA's Zero Trust Maturity Model for the Data pillar:

• Every access request is authenticated and authorized cryptographically, not by network position or inherited credentials.
• Access decisions are continuous and dynamic. Policies can enforce time windows, device posture, geographic restrictions, and MFA requirements at the moment of decryption, not just at login.
• Access is revocable in real time. When trust is withdrawn, whether because a vendor contract expires, an employee changes roles, or a breach is detected, decryption capability is removed immediately across the entire ecosystem.
• Audit trails are tamper-evident and independent of the systems storing or processing PHI, ensuring that even compromised infrastructure cannot hide access events.

For healthcare organizations pursuing Zero Trust maturity, or responding to federal mandates such as Executive Order 14028 and its successors, record-level encryption provides the component that network-centric and identity-centric tools cannot deliver on their own.

8. How Seald Healthcare Works

Seald Healthcare provides record-level encryption purpose-built for healthcare. PHI is encrypted at the source and protection is maintained across every system, vendor, and workflow the data touches.

8.1 Record-Level Encryption for Healthcare

PHI is encrypted at the record level and only decrypted by authorized recipients. No intermediary, including Seald Healthcare itself, can access plaintext data. This is persistent, record-level encryption where the cryptographic keys are independent of the infrastructure.

Unlike consumer end-to-end encryption, Seald Healthcare's model was designed from the ground up for healthcare's multi-party access requirements. A single patient record can be accessible to the treating physician, consulting specialists, the billing team, and the insurance payer, each with different permission levels, all enforced cryptographically.

8.2 Policy-Governed Access Controls

Policy-governed access controls remain attached to the data itself. Healthcare organizations can define exactly who can access data, from which devices, during which time windows, under which conditions (geographic, network, or MFA requirements), and for how long.

These policies are cryptographically enforced at the point of decryption, not at the network perimeter. They can be modified or revoked at any time, even after data has been shared. When a vendor's contract expires, access is revoked. When a staff member changes roles, permissions update automatically. When a security incident is detected, access can be suspended across the entire ecosystem in real time.

8.3 Policy Studio, Powered by Marlow

Policy Studio, powered by Marlow, the AI that operates Seald Healthcare, allows administrators to translate governance rules, Business Associate Agreements, vendor agreements, and internal access requirements into enforceable policies. Instead of configuring complex rule engines or writing security policies in technical syntax, an administrator can describe the requirement in plain language or upload a signed contract or BAA.

Marlow analyzes the agreement, drafts the corresponding access conditions, checks them against active policies and recent decryption activity, and stages policy updates, key rotations, access changes, and session revocations for approval. Once approved, Seald Healthcare enforces those policies cryptographically at the record level on every decryption request.

8.4 Chain of Custody and Tamper-Evident Audit Trails

Every access event, whether it is a successful decryption, a denied access attempt, a policy change, a key rotation, or a permission modification, is logged with cryptographic integrity. These logs cannot be altered without detection. They record who accessed data, when, from where, and from which device. They provide evidence-grade records for compliance audits, breach investigations, regulatory inquiries, and legal proceedings. They are maintained independently of the systems storing or processing PHI.

Together with cryptographic signing, this audit trail gives organizations a verifiable chain of custody for every record. Every access, change, addition, and deletion is attributed to a person, application, or AI agent, tied to the policy that authorized it, and recorded so that any later alteration can be detected.

Seald Healthcare also turns this record into evidence. Marlow summarizes protection status for any scope and time period, and organizations can generate a hash-verified, tamper-evident evidence pack in minutes for auditors, insurers, and regulators.

8.5 Developer-First Integration: SDK and API

Seald Healthcare integrates into existing healthcare workflows through a flexible, developer-first model that includes both SDK and API access. The Seald Healthcare SDK can be embedded into applications, integration engines, patient portals, telehealth platforms, file-sharing systems, data pipelines, and custom internal tools.

Seald Healthcare can also deploy at the egress point through APIs and gateways, protecting PHI as it leaves the EHR without requiring changes to the EHR itself. For server-side orchestration and third-party data exchange, Seald Healthcare provides APIs that enable encryption, policy-governed decryption, and interoperability across systems.

Seald Healthcare supports single sign-on with existing identity providers, ensuring authentication aligns with established organizational identity systems. Staff continue using the same clinical and administrative systems they use today, while encryption and policy enforcement are applied at the record level across environments including AWS, Google Cloud, and Azure.

8.6 Automatic Key Management

Key management is one of the most complex challenges in applied cryptography and a common point of failure in real-world systems. Seald Healthcare manages this complexity through a fully automated, policy-driven, zero-knowledge architecture.

Encryption keys are issued, rotated, rewrapped, and revoked automatically without manual intervention. The key infrastructure is managed separately from the encrypted data, and each data key is itself encrypted under a key controlled by the customer's organization. As a result, Seald Healthcare cannot unwrap the data keys or decrypt the customer's PHI.

Key release is evaluated at decrypt time under the organization's active policies. Cloud administrators, infrastructure operators, vendors, and Seald Healthcare cannot produce plaintext without the required cryptographic authorization. The key lifecycle follows NIST best practices and is designed to support migration as post-quantum standards are adopted across the industry.

8.7 Group and Role-Based Access

Healthcare is organized around teams, departments, and roles, not individual users. Seald Healthcare supports this structure natively. Permissions can be assigned to care teams, departments, or roles rather than individuals. Access updates automatically as group membership changes. When a physician joins a department, they gain access to that department's encrypted data without manual provisioning. When a nurse transfers to another unit, permissions adjust accordingly. The system supports the complex access patterns healthcare demands: primary care teams, consulting specialists, and administrative staff can each hold different permission levels on the same data.

9. Performance, Latency, and Availability

Healthcare workflows are latency-sensitive. EHR response times, real-time claims adjudication, lab result delivery, and clinical decision support all require near-instantaneous data access. Record-level encryption with policy enforcement at the point of decryption introduces overhead that must be addressed transparently.

9.1 Performance Architecture

Seald Healthcare is engineered to minimize latency impact on clinical and administrative workflows. Our distributed, multi-vendor hybrid cloud architecture maintains a 99.999% uptime SLA, ensuring encryption and decryption services are consistently available when patient data is needed.

Typical key request round-trip latency is under 50 milliseconds, and decryption leverages hardware-accelerated cryptographic modules available on modern CPUs. For high-throughput workloads, bulk data processing is supported via GPU acceleration (CUDA).

9.2 Availability and Business Continuity

In healthcare, system availability is a life-safety requirement. A security platform that prevents providers from accessing patient data during an outage introduces unacceptable clinical risk. Seald Healthcare is designed with this constraint as a core principle.

Our geographically distributed, multi-vendor hybrid cloud architecture, combined with intelligent routing and on-demand backup systems, provides high resiliency and fault tolerance. For enterprise customers, Seald Healthcare also supports on-premise deployments, including air-gapped environments, enabling additional redundancy, lower latency, and operational control.

9.3 Business Continuity and Key Recovery

Seald Healthcare supports controlled key recovery and business-continuity mechanisms without compromising its zero-knowledge architecture. Recovery material remains protected under cryptographic authority controlled by the customer's organization, so Seald Healthcare cannot independently unwrap data keys or decrypt PHI.

Recovery occurs only through defined, authorized procedures designed to preserve availability while maintaining separation between encrypted data and decryption authority. Additional technical details are available upon request.

10. Interoperability: FHIR, TEFCA, and Information Blocking

Healthcare data exchange is increasingly governed by interoperability mandates. The ONC's 21st Century Cures Act information blocking rules require that healthcare providers do not unreasonably restrict the access, exchange, or use of electronic health information. FHIR (Fast Healthcare Interoperability Resources) APIs have become the standard for clinical data exchange, while TEFCA (Trusted Exchange Framework and Common Agreement) is establishing a nationwide framework for health information exchange across networks.

A common concern is whether encrypting protected health information (PHI) at the record level introduces friction with these requirements. It does not. Record-level encryption secures the payload while allowing authorized access when required.

When a payer, provider, or health information exchange requests data under interoperability rules, the requesting entity is evaluated against defined access policies. If authorized, the data is decrypted at the destination endpoint. The interoperability obligation is fulfilled without exposing sensitive data beyond what is necessary.

PHI moving through FHIR APIs remains encrypted in transit and at rest across intermediate systems. Only the authorized endpoint receives plaintext. If a FHIR server, HIE node, or TEFCA-qualified network is compromised, the exposed data remains encrypted.

Rather than limiting interoperability, record-level encryption strengthens it. Interoperability depends on trust. Organizations are more willing to exchange data when they retain control over it. A primary barrier to participation in health information exchanges and FHIR-based integrations is the loss of control once data leaves the organization. Seald Healthcare addresses this by enforcing policy-based access, along with post-share governance and revocation capabilities.

At scale, safe interoperability requires a shift in architecture. Data must remain protected regardless of the systems, networks, or vendors involved. Seald Healthcare enables this model by enforcing persistent, policy-controlled protection of sensitive data across the healthcare ecosystem.

11. What This Looks Like in Practice

Abstract security concepts become more meaningful when applied to real-world healthcare scenarios.

11.1 Vendor Breach

Without record-level encryption: A revenue cycle management vendor is breached. The vendor has access to plaintext PHI for millions of patients across multiple healthcare organizations. As a result, sensitive patient data is fully exposed. The healthcare organization may not become aware of the breach for weeks and has no ability to limit further exposure. This pattern reflects incidents such as the Change Healthcare cyberattack.

With Seald Healthcare: In a Seald Healthcare-protected workflow, PHI passing through or stored by the vendor remains encrypted except during policy-authorized use. If the vendor environment is breached, the attacker obtains ciphertext rather than readable patient data unless the separate decryption requirements are also satisfied. The healthcare organization can revoke future decryption access in real time, while the tamper-evident audit trail shows what records were accessed before revocation.

11.2 Insider Threat

Without record-level encryption: A database administrator with broad system access exfiltrates patient records. Traditional access controls cannot prevent individuals with legitimate administrative credentials from querying and extracting sensitive data. The organization may not detect the activity for months, often through an unrelated investigation. In 2024, a former employee at Nuance Communications, a contractor for Geisinger, accessed records of over 1.2 million patients after termination due to delayed credential revocation (HIPAA Journal).

With Seald Healthcare: The administrator can still access the database, but cannot decrypt PHI because decryption keys are managed independently of infrastructure credentials. Data stored in the database remains encrypted. All access attempts are recorded in a tamper-evident audit trail, with real-time alerts enabling immediate detection and response.

11.3 Ransomware Attack

Without record-level encryption: Attackers exfiltrate PHI before deploying ransomware. Even if the organization successfully restores operations, the stolen data remains permanently exposed. This results in regulatory penalties, class-action litigation, and long-term reputational damage. UnitedHealth Group reported $3.1 billion in costs associated with a single ransomware incident.

With Seald Healthcare: Attackers may still exfiltrate data, but it remains encrypted. Without access to decryption keys, the data is unusable. The organization can demonstrate to regulators and patients that PHI was never exposed in plaintext. Under HIPAA's encryption safe harbor provision, breach notification requirements may not apply, as encrypted data is not classified as “unsecured PHI” under the Breach Notification Rule.

11.4 Tracking Technology Exposure

Without record-level encryption: Website tracking pixels from Google, Meta, or other advertising platforms inadvertently capture and transmit patient data to third parties. Kaiser Foundation Health Plan exposed 13.4 million member records this way in 2024. The data was sent to advertising companies in plaintext (HIPAA Journal).

With Seald Healthcare: Even if tracking technologies capture data fields, the underlying PHI is encrypted. What gets transmitted is ciphertext. The advertising platform cannot read it. The exposure is neutralized.

12. The Encryption Safe Harbor

The HIPAA Breach Notification Rule (45 CFR Parts 160 and 164, Subparts D and E) requires covered entities and business associates to notify affected individuals, the Department of Health and Human Services (HHS), and in some cases the media when a breach of unsecured PHI occurs. The key distinction is “unsecured.”

HHS defines unsecured PHI as protected health information that has not been rendered unusable, unreadable, or indecipherable to unauthorized individuals. Guidance issued by the Secretary identifies two methods to achieve this standard: encryption consistent with NIST guidelines and destruction. If PHI is encrypted in accordance with NIST standards at the time of a breach, it is not considered unsecured PHI, and breach notification requirements may not apply.

This framework is commonly referred to as the encryption safe harbor, and it has significant financial implications for healthcare organizations.

Without safe harbor protection, a breach triggers a cascade of operational, financial, and legal consequences:

• Individual notification costs: Organizations must notify each affected individual. For large-scale breaches, these costs can reach hundreds of millions of dollars. The Change Healthcare cyberattack, which impacted approximately 192.7 million individuals, illustrates the scale of this burden.
• HHS notification and public disclosure: Breaches affecting more than 500 individuals are published on the HHS breach portal, often referred to as the “Wall of Shame,” where they remain permanently. This drives media attention and long-term reputational impact.
• Media notification: Breaches affecting more than 500 residents within a single jurisdiction require notification to prominent local media outlets.
• Regulatory investigation and penalties: Notification typically triggers investigation by the Office for Civil Rights (OCR), with potential financial penalties.
• Class-action litigation: Public disclosure frequently leads to class-action lawsuits, which have followed nearly every major healthcare breach in recent years.
• Cyber insurance impact: Breach-related claims increase premiums and may exceed coverage limits.
• Patient churn and revenue loss: Breach notifications erode patient trust and can lead to loss of business.

When PHI is encrypted in accordance with NIST standards at the time of a breach, the outcome is materially different. The organization can demonstrate that the data was secured under HIPAA's definition. In many cases, breach notification requirements do not apply. This avoids the downstream consequences associated with notification, including public disclosure, regulatory scrutiny, and litigation risk.

For financial and legal leadership, this is not a theoretical benefit. It is a measurable reduction in risk exposure. The average cost of a healthcare data breach is $6.64 million (IBM, 2026), with a significant portion driven by notification, investigation, and legal expenses that safe harbor protection can mitigate.

Seald Healthcare's encryption architecture is designed to meet the NIST standards specified in HHS guidance. PHI encrypted with Seald Healthcare is rendered unusable, unreadable, and indecipherable to unauthorized individuals, satisfying the requirements for encryption safe harbor.

13. Why This Cannot Wait

Several converging forces are making record-level security an immediate priority for healthcare organizations.

13.1 Third-Party Risk Is Accelerating

Recent breaches, including the Change Healthcare cyberattack and the MOVEit data breach, demonstrate how vendor compromises can cascade across the healthcare ecosystem. A single breach at a third-party provider can expose data from dozens or even hundreds of organizations.

A large hospital may work with hundreds to thousands of third-party vendors (Ponemon Institute), significantly expanding the attack surface. In 2024, breaches involving business associates accounted for a disproportionate share of compromised records (HIPAA Journal). This risk is increasing as healthcare organizations continue to rely on external vendors for critical functions.

13.2 Regulatory Enforcement Is Tightening

Regulatory expectations for healthcare cybersecurity are increasing in both scope and enforcement. In December 2024, the Department of Health and Human Services (HHS) published a proposed update to the HIPAA Security Rule that would require organizations to implement controls such as multifactor authentication, encryption for data at rest and in transit, network segmentation, and ongoing security testing. Many of these measures have historically been treated as addressable rather than mandatory (HIPAA Journal; HHS NPRM, 2024).

Enforcement activity is also accelerating. The Office for Civil Rights (OCR) imposed 21 financial penalties in 2025 and has expanded its focus beyond breach response. Its 2026 enforcement priorities include broadening the Risk Analysis Initiative to encompass risk management, requiring organizations to demonstrate not only that risks are identified, but that they are actively mitigated in a timely manner (HIPAA Journal, 2025 Report). State attorneys general are increasing enforcement as well, adding another layer of regulatory pressure at the state level.

13.3 State-Level Privacy Laws Are Expanding Beyond HIPAA

HIPAA provides a federal floor, but a growing number of states are building well above it. Healthcare organizations operating across state lines now face a patchwork of health data privacy laws that impose additional obligations, broader definitions of protected information, and in several cases, private rights of action or aggressive attorney general enforcement that HIPAA itself does not provide.

Washington

Washington's My Health My Data Act, signed into law in April 2023, was the first state law in the country specifically designed to protect consumer health data that falls outside HIPAA's scope. The law applies broadly to any entity that conducts business in Washington or provides products or services targeted to Washington consumers, and it covers health data generated by apps, wearables, and online platforms in addition to traditional clinical data. Critically, any violation of the Act is a per se violation of the Washington Consumer Protection Act, which is enforceable by both the attorney general and through private right of action. Washington's attorney general has been among the most aggressive in the nation on data privacy enforcement, securing a $39.9 million settlement from Google over deceptive location tracking practices rather than joining a less lucrative multistate settlement.

California

California operates under multiple overlapping health data privacy frameworks that go far beyond HIPAA. The Confidentiality of Medical Information Act (CMIA), which predates HIPAA by more than 15 years, applies to a broader set of entities than HIPAA and imposes stricter standards on how medical information can be collected, used, and disclosed. A key difference from HIPAA is CMIA's private right of action, which allows patients to sue for negligent unauthorized disclosures even when there was no intent to cause harm. The California Consumer Privacy Act (CCPA) as amended by the California Privacy Rights Act (CPRA) gives consumers a private right of action for data breaches, with statutory damages ranging from $107 to $799 per consumer per incident. The California Attorney General has been active in enforcement, securing a $2.75 million settlement against Disney in 2026 and a $93 million settlement against Google in 2023. In September 2025, Governor Newsom signed AB-45, which strengthens protections for health-related location data, restricts geofencing around healthcare facilities, and provides a limited private right of action for violations. New regulations finalized by the California Privacy Protection Agency took effect January 1, 2026, including requirements for cybersecurity audits by businesses processing significant volumes of sensitive data.

New York

New York passed the Health Information Privacy Act (NYHIPA) through its legislature in January 2025, establishing one of the broadest health data privacy frameworks in the country. The bill defines “regulated health information” expansively to include any data reasonably tied to an individual and related to physical or mental health, including location and payment information. While Governor Hochul vetoed the 2025 version in December 2025, a revised version was reintroduced in the 2026 legislative session with expanded exemptions and modified penalty structures but the same fundamental framework. The New York Attorney General would have exclusive enforcement authority with civil penalties of up to $15,000 per violation. New York also recently amended its data breach notification law (General Business Law 899-aa) to expand the definition of “private information” to include medical and health insurance information and to impose a 30-day notification deadline, one of the shortest in the nation. Whether NYHIPA passes in 2026 or a subsequent session, the trajectory is clear: New York is moving aggressively to regulate health data beyond HIPAA's reach.

New Jersey

The New Jersey Data Privacy Act (NJDPA), effective January 2025, gives the New Jersey Attorney General enforcement authority with penalties of up to $10,000 for initial violations and $20,000 for subsequent offenses, plus investigative costs and attorney's fees under the Consumer Fraud Act. While the NJDPA exempts PHI processed by HIPAA covered entities and business associates, healthcare businesses that process personal data beyond traditional PHI, such as promotional emails to non-patients, consumer-facing wellness services, or telehealth platforms where users sign up directly, are subject to the law's full requirements. The cure period for violations sunsets in July 2026, after which enforcement proceeds without a grace period.

Connecticut, Nevada, Colorado, and Virginia

Connecticut amended its consumer data privacy act to impose transparency requirements and restrictions on consumer health data similar to Washington's My Health My Data Act. Nevada passed its own consumer health data privacy law with provisions modeled on Washington's approach. Colorado's Privacy Act, effective since July 2023, covers health and sensitive data with strict opt-in consent requirements and mandates data protection assessments for high-risk processing activities, with civil penalties reaching $20,000 per violation. Virginia amended its Consumer Protection Act in 2025 to focus on consumer health data privacy related to reproductive and sexual health information.

The Enforcement Reality

State attorneys general, particularly in California, New York, New Jersey, and Washington, have demonstrated a willingness to pursue enforcement actions and support class-action litigation that goes well beyond anything HHS OCR has attempted under HIPAA. The private rights of action available under Washington's My Health My Data Act, California's CMIA and CCPA, and Connecticut's amended privacy law create litigation risk that is independent of federal enforcement. For healthcare organizations operating in multiple states, the compliance burden is substantial and growing. Record-level encryption provides a technical foundation that satisfies the most stringent requirements across all jurisdictions simultaneously, because data that is cryptographically secured at the source is protected regardless of which state's law applies.

13.4 Cyber Insurance Is Demanding More

Cyber insurers are shifting away from compliance checklists toward requiring demonstrable technical controls as a condition of coverage. Organizations that cannot demonstrate effective data protection measures will face higher premiums, reduced coverage, and exclusions that increase financial exposure in the event of a breach.

13.5 Post-Quantum Cryptography Is Coming

NIST has finalized its first post-quantum cryptographic standards (FIPS 203, 204, and 205), and organizations across industries are beginning to plan for migration or at least they should. Healthcare organizations that have not modernized their cryptographic architecture will face costly and disruptive upgrades as these standards are adopted. Seald Healthcare's architecture is designed to support quantum-safe cryptographic migration, providing strong protection today while enabling a seamless transition as standards evolve (NIST, 2024).

14. Getting Started

Adopting record-level security does not require replacing existing infrastructure. Seald Healthcare is designed to layer on top of current systems, complementing existing security investments while addressing the gaps left by perimeter-based approaches.

Seald Healthcare supports three integration paths.

Secure Portal Access protects workflows where an authorized person reviews records through a browser without requiring vendor integration.

Native Integration uses Seald Healthcare's API or SDK for applications, services, vendors, analytics systems, and AI workflows that process records by machine.

Protected Storage keeps databases, cloud storage, backups, and archives encrypted, encrypting PHI on write and separating the key infrastructure from the stored data.

Organizations can begin with a single workflow, such as files in OneDrive, Google Drive, or S3, and protect it in minutes. Native integrations then roll out vendor by vendor, with help from our forward-deployed engineers. There is no requirement to replace existing infrastructure or encrypt every workflow at once.

Record-level security does not replace existing security infrastructure. Firewalls, identity providers, SIEM systems, and endpoint protection remain in place. Seald Healthcare adds a layer of cryptographic protection that these systems do not provide. Even if perimeter controls fail, data encrypted with Seald Healthcare remains unreadable without explicit authorization.

15. Conclusion

Healthcare's security model was built for a perimeter. AI has dissolved it.

The numbers are clear. More than 1 billion patient records have been compromised since 2009, including more than 289 million in 2024 alone. A single breach affected 192.7 million individuals. Healthcare has had the highest breach costs of any industry for 13 consecutive years. Enforcement actions are increasing, litigation is expanding, and third-party risk continues to grow. At the same time, a fragmented landscape of state-level privacy laws is creating new layers of liability that HIPAA was not designed to address. AI adoption is introducing entirely new categories of data exposure.

Compliance frameworks and cloud platforms remain essential. They provide baseline protections, operational discipline, and regulatory alignment. However, they were not designed to secure PHI as it moves across the modern healthcare ecosystem, an environment defined by hundreds of vendors, thousands of integration points, and millions of daily data transactions.

The gap is structural. Perimeter-based security protects systems. Record-level security protects data. Healthcare requires both.

Closing this gap requires a shift in architecture. Data must be encrypted at the source, governed by persistent policies that travel with it, and tracked through a verifiable chain of custody for every access and change. It must remain secure across systems, networks, and vendors, and be prepared for the transition to quantum-resistant cryptography.

For interoperability to function at national scale through FHIR APIs, TEFCA, and health information exchanges, the data itself must remain protected end-to-end. Without this foundation, the industry is extending nationwide data exchange on the same plaintext architecture that has already resulted in hundreds of millions of compromised records.

Organizations that make this shift will be better positioned to meet evolving regulatory expectations and insurance requirements, and to deploy AI with a chain of custody they can prove. Those that do not will remain dependent on perimeter-based models that were not built for how patient data moves today.

Learn more at www.sealdhealthcare.com or contact [email protected].