“The code is more what you’d call guidelines than actual rules,” Captain Barbossa famously quipped in Pirates of the Caribbean. Some healthcare organizations may be tempted to view the Health Insurance Portability and Accountability Act (HIPAA) Security Rule’s (Rule) “addressable” implementation specifications the same way. The Office for Civil Rights (OCR); however, has made clear that addressable does not mean optional.

Key Takeaways

• Security Rule “Addressable” Specifications are not optional: Covered entities and business associates must implement the specification, adopt a reasonable equivalent alternative, or thoroughly document why the specification is not reasonable or appropriate for the organization. 
• A decision not to implement the specification as written requires a  comprehensive risk analysis of size, resources, existing safeguards, costs, technical capabilities, and the organization’s specific environment—and that analysis must be documented.
• Failure to document the assessment and rationale can itself result in a finding of noncompliance, even if the underlying conclusion was reasonable.

Required and Addressable: What the Rule Actually Says

The HIPAA Security Rule sets forth a number of general requirements for technical safeguards. For example, covered entities and business associates must implement procedures to record and examine activity in systems that contain electronic protected health information (ePHI) and procedures to verify the identity of someone seeking access to ePHI, among other requirements. The Rule also includes two categories of technical implementation specifications: required and addressable.

If an implementation specification is required, a healthcare organization must implement it as written. There is no discretion to substitute an alternative safeguard or forgo implementation based on any assessment. By contrast, addressable implementation specifications provide flexibility and permit HIPAA covered entities and business associates to evaluate whether the specification is reasonable and appropriate for a particular organization.

This flexibility is intentional, and the “addressable” category was created to provide organizations the opportunity to consider their size, resources, security framework, risk analysis and security measures already in place when determining the applicability of an addressable specification. OCR understands that a large urban health system and a small rural physician’s office face different operational realities and that certain Rule requirements are not necessarily a one-size fits-all solution to data security.

Therefore, if a covered entity or business associate determines an addressable specification is not appropriate and reasonable for its organization, it has two options: The organization may: (1) adopt an appropriate and reasonable alternative measure that achieves the same objective; or (2) decide not to implement the specification as written, or any reasonable alternative, at all.

In either scenario, the organization must reach this conclusion through a thoughtful, comprehensive risk-based analysis and thoroughly document its rationale. Failure to document the analysis may result in a finding of noncompliance – even where the ultimate decision not to implement the specification was reasonable.

The Specifications That Create the Most Problems

In our experience, a handful of addressable specifications attract disproportionate OCR scrutiny, and they illustrate why documentation matters.

• Encryption of ePHI in transit: Under 45 C.F.R. § 164.312(e), covered entities and business associates must protect ePHI transmitted over electronic communications networks, with encryption identified as an addressable implementation specification. Given the increasing accessibility and relative cost-effectiveness of solutions for encrypting ePHI in transit, organizations that determine this obligation is not reasonable or appropriate, or rely on an alternative, should thoughtfully evaluate and document their conclusion. Given the widespread availability and relatively low cost of encryption technologies, organizations that fail to implement encryption – or an attempt to duplicate its effectiveness via an alternative method –invites heavy scrutiny from OCR and state attorneys general.
• Encryption of stored ePHI: The requirement to encrypt ePHI at rest on devices and systems is also addressable (45 C.F.R. § 164.312(a)(2)(iv)). Healthcare companies that store ePHI on unencrypted laptops, drives or servers without a documented rationale face meaningful regulatory exposure. However, encrypting ePHI at rest within a health system’s internal network, for example, can encumbering provider and workforce member access and potentially interfere with patient care. Thus, organizations must carefully analyze the propriety of encryption at rest for various ePHI repositories, depending on their use and function.  That said, there is rarely a scenario where ePHI should not be encrypted at rest on a portable device, like a laptop, which pose a greater risk of exposure through loss or left.  The 2026 BakerHostetler Data Security Incident Response Report further confirms that device loss and theft are ongoing challenges for covered entities and business associates
• Automatic logoff: 45 C.F.R. § 164.312(a)(2) requires covered entities and business associates to ensure access to ePHI is limited to only authorized people or programs, with automated logoff after a predetermined time of inactivity as an addressable implementation specification. Because automatic logoff functionality is commonly available – and even the default – in modern clinical and business applications, any decision to forego automatic logoff for systems containing ePHI is likely to receive substantial scrutiny.  However, organizations that require rapid access to certain devices for patient care might reasonably conclude that automated logoff functions should be adjusted or limited.  Factors relevant to this conclusion may include the physical security and general accessibility of the location where the device is used, the likelihood of unauthorized access, the proximity of the user when the device is not actively in use, and why automated logoffs would interfere with patient care. 

Documenting a Defensible Decision

OCR makes clear that a decision to implement an alternative specification, or not to implement a specification at all, depends on a variety of factors, including the covered entity’s or business associate’s security risk analysis and risk mitigation strategy, what security measures are already in place, and the cost of implementation. Other relevant factors include the size of the organization, its resources relative to the cost of the implementation specification, the complexity and technical capabilities of the organization, and any other unique factor related to the reasonableness or appropriateness of the particular specification. The relevance of each factor may vary depending on the specification and the organization.

For each addressable specification, healthcare companies should be able to answer the following:

• Did we assess this specification, and when?
• What factors, including our size, environment and existing controls, did we consider?
• What did we decide, and why?
• If we implemented an equivalent alternative, how does it provide the same type of protection?
• When did we last revisit our assessment, and does it reflect our current environment?

The answers do not have to be verbose, but they should be thoughtful, current and documented. A healthcare company that can answer those questions for each addressable specification is in a fundamentally better position in an OCR investigation than one that cannot.

BakerHostetler can help healthcare organizations evaluate addressable specifications, develop defensible documentation and assess areas that have historically attracted OCR scrutiny. The objective is not to identify a universally “correct” answer but to ensure the organization can demonstrate a thoughtful, risk-based decision-making process.

Not the Pirate’s Code

Captain Barbossa’s approach to the pirate code worked well enough on the high seas. In an OCR investigation, it will not.

Healthcare organizations that treat addressable specifications as optional are not enjoying flexibility. They are creating exposure. In many OCR investigations, the critical issue is not whether the organization reached a particular conclusion but whether it can demonstrate how and why that conclusion was reached. The difference between an organization that can produce a documented good faith assessment and one that cannot is often the difference between a manageable investigation and a resolution agreement, penalty or fine.

This post is part of a series on practical HIPAA Security Rule compliance. It draws on themes explored in “HIPAA at 21 Years of Compliance: Why the Security Rule May Be Entering a More Prescriptive Era,” published by BakerHostetler, and data from the 2026 DSIR.

T-Mobile disclosed a security incident in August 2021 that involved 76 million records (approximately 47 million had SSNs). The notification requirement of Washington’s data breach notice law is similar to most states – if there is a notice obligation, the notice has to be provided by sending a letter by regular mail, an email if there is E-Sign consent, or substitute notice (and substitute notice requires a press release, a posting on the company’s website and an email if the company has an email address for the individuals to be notified). Washington’s notification law, like many other states, also has content requirements (e.g., the notice has to include the name of and contact information for the company, the data elements involved and the date of the breach). Washington’s law also provides that if a company has an internal notice procedure and issues notice that meets Washington’s notification time requirement, the company complies with Washington law by following its policy. T-Mobile sent a text message as its method of notice to 361,030 Washington residents.

The Washington Attorney General filed a lawsuit against T-Mobile in January 2025 alleging that T-Mobile committed violations of Washington’s consumer protection law by not providing notice in compliance with the requirements of Washington’s data breach notice law. A Washington state court issued a decision in July 2026 granting summary judgment in favor of Washington. The court determined that T-Mobile’s text message resulted in two separate violations of Washington’s law for each of the 361,030 residents: (1) the method of notice did not meet the substitute notice requirements and (2) the words in the text message did not meet the content requirements. Washington law permits the recovery of a civil penalty of not more than $7,500 for each violation. Using a penalty of just $100 per violation for the 722,060 violations, T-Mobile would face a civil penalty of $72 million (an amount per violation at the top end would impose billions in civil penalties).

T-Mobile filed a motion in August 2026 seeking reconsideration of the summary judgment ruling. The motion argued that the court should not have granted summary judgment without (1) evaluating whether T-Mobile substantially complied with Washington’s notice law because the text message contained a link to a post on T-Mobile’s website that contained all required content and (2) addressing whether T-Mobile complied with Washington law by following T-Mobile’s notice procedure. T-Mobile also attacked the double-counting of violations, asserting that the order imposes more liability on T-Mobile for how it provided notice than if T-Mobile had not provided any notice. Presumably, if T-Mobile had not provided any notice, Washington could argue that there were at least four separate violations: (1) not providing timely notice, (2) not providing notice by the required method, (3) not providing the required content in the notice and (4) not notifying the Washington Attorney General.

Companies addressing significant security incidents face a lot of challenges and risks. Individuals who are notified can bring lawsuits. Regulators can investigate to determine if the company had a reasonable security program. Providing notice in a manner that leaves the door open for a regulator to allege that there were areas of noncompliance with notice requirements (e.g., timing, method, content) adds an extra layer of risk and often sends an invitation for further inquiry where it otherwise would not exist (especially at a time when state attorneys general collaboration is high).

Cryptographically relevant quantum computers (CRQCs) will be more than just a technological breakthrough. They will herald novel security risks and reshape legal risk across the data lifecycle. As discussed in our prior post, threat actors are already exploiting the underlying vulnerability through harvest-now-decrypt-later (HNDL) attacks, where sophisticated adversaries intercept encrypted telecommunications to prepare for later decryption. Thus, CRQCs will not only introduce new data security incidents, but could also retroactively alter the significance of an adversary’s past actions if they allow the adversary to decrypt previously compromised-but-encrypted data that remains sensitive over time. CRQCs will also introduce structural vulnerabilities in systems that rely on asymmetric cryptography, including identity infrastructure and blockchain networks. The threat of CRQCs is already reshaping incident response strategies, legal risk and the relevant standards of care.

This post examines how legal risks may arise and develop. It first addresses the types of data security incidents that will become possible or materially worse when CRQCs become available. Understanding these incident pathways is essential to identifying which compromises carry meaningful quantum exposure. It then turns to the legally novel dimension of retrospective risk, including how future decryption may reopen prior breach analyses and trigger new notification, litigation or insurance disputes. The post also examines systemic and hard-to-remediate risk in blockchain ecosystems and smart contracts, and concludes with the evolving regulatory standard of care as governments increasingly signal that organizations should begin preparing for quantum threats now.

New Data Security Incidents at the Arrival of CRQCs

Organizations will face new legal risks as CRQCs become operational, commercialized and widely available. The most obvious risk is the potential for new, severe data security incidents as the tech ecosystem’s defensive layers break down if not first adequately protected by post-quantum cryptography (PQC). Systems at risk include:

• Transport Layer Security (TLS). Attackers who intercept RSA- or ECC-encrypted HTTPS traffic – such as through BGP hijacking, compromised network infrastructure or rogue access points – could use CRQCs to decrypt the traffic. This includes secure web traffic, API calls and interactions with cloud services. Even forward-secret implementations of TLS (mandatory in TLS 1.3; optional in TLS 1.2) that rely on ephemeral key exchanges (like DHE or ECDHE) will be vulnerable because Shor’s algorithm could derive ephemeral private keys from publicly exchanged key material. In addition, breaking a certificate authority’s keys could allow attackers to forge TLS certificates for arbitrary domains, allowing man-in-the-middle attacks at scale.
• Authentication systems. CRQCs could break digital certificates, PKI hierarchies and code-signing infrastructure that rely on RSA or ECC. This could enable attackers to impersonate other entities, issue fraudulent software updates or forge authentication tokens (e.g., JWTs or SAML assertions for SSO). Compromised SSH keys could enable direct server login, with no credential theft required.
• VPNs and encrypted communications. CRQCs could break enterprise VPNs and secure messaging applications that depend on RSA- or ECC-based session key negotiation, exposing intercepted traffic.
• Data at rest. Many enterprise cryptographic systems protect data with “envelope encryption”: generating a random file- or object-level symmetric encryption key, then locking that key using an RSA or ECC “wrapper” key. This structure is widely used by public-key cloud key management services, encrypted email, enterprise document protection and HSM-backed key transport systems. A threat actor who compromises both encrypted data and its wrapped key material could decrypt the data even where the underlying symmetric encryption would otherwise be quantum resistant. In addition, Grover’s algorithm theoretically reduces the effective security of AES-128. While practical quantum attacks against AES-128 will likely remain far more difficult than attacks against public-key cryptography, the contents of any system using AES-128 for long-term confidentiality – encrypted databases, archived files, backup storage or data at rest in cloud environments – could be at risk if compromised.

Collectively, these attacks pose serious threats to encryption vulnerable to CRQCs. But not every incident carries added risk in a post-quantum world. The incidents that present novel risk generally share a specific structural feature: The threat actor obtained not just encrypted data but also the asymmetric cryptographic material (i.e., the public key) from which decryption keys can be derived. This means the highest-risk incidents are those involving network-level interception of traffic (where the key exchange itself traversed the wire and can be broken by Shor’s algorithm), exfiltration of encrypted data alongside asymmetrically wrapped encryption keys (such as PGP-encrypted archives, S/MIME messages or cloud-stored objects with RSA-wrapped data keys) or theft of PKI public keys that anchor trust hierarchies.

By contrast, the majority of conventional data breaches present little or no added quantum risk. An attacker who exfiltrated a database in plaintext already has the data. An attacker who stole credentials or session tokens obtained access, not ciphertext. And an attacker who compromised an endpoint and downloaded files encrypted purely with AES-256 likely does not practically benefit from a quantum shortcut.

Legally, quantum-enabled incidents lend themselves to familiar risk frameworks. Unauthorized access to protected data, compromise of authentication systems, and loss of confidentiality or integrity are all relevant concepts. Over time, as the quantum threat becomes more widely discussed and the availability of PQC increases, courts and regulators will be more likely to view these incidents as foreseeable and preventable.

Contemplating CRQCs in Incident-Related Risk Assessments

As CRQCs approach maturity, organizations will need to increasingly consider their impact on incident-related risk assessments. Many global breach notification laws – such as the GDPR and many U.S. state laws – effectively do not impose notice obligations where data is encrypted with a secure algorithm. But these provisions generally apply only if the encryption algorithm and implementation are secure. When CRQCs reach maturity, the security afforded by certain encryption, in certain incidents, may be less certain, requiring entities to consider their risk assessments carefully.

The European Data Protection Board’s (EDPB) guidelines on personal data breach notification already point to this concern, noting that although “a confidentiality breach involving properly encrypted personal data may not need to be notified . . . because such a breach is unlikely to pose a risk to individuals’ rights and freedoms . . . this may change over time and the risk would have to be re-evaluated” – for example, “[i]f it later becomes evident that the encryption key was compromised” or that the underlying “encryption software or algorithm is vulnerable.”

The possibility of past incidents turning into newly actionable data breaches could also pose distinct cyber insurance risks.

Blockchain and Smart Contract Risks

Blockchain presents some of the most distinctive and difficult-to-remediate quantum risks. Many major public blockchains – including Bitcoin and Ethereum – rely extensively on ECC using the secp256k1 curve. A CRQC running Shor’s algorithm could derive private keys from exposed public keys. Ethereum’s consensus layer also relies on BLS12-381 signatures, while its scaling infrastructure uses KZG polynomial commitments, both of which are independently vulnerable to Shor’s algorithm.

Addresses where the public key is already visible on-chain will be vulnerable as soon as CRQCs are available. On-chain public key visibility occurs when, for example, an address is used to send a transaction, exposing the public key, and then reused. It also affects addresses that were used to receive a transaction in the early days of cryptocurrency with Pay-to-Public-Key transactions. A recent Google whitepaper estimates that approximately BTC 6.9 million (approximately USD 500 billion) are held in vulnerable addresses. Unlike the classic HNDL threat, where an adversary must have already intercepted data in transit, the permanence of the blockchain ledger means no prior access is required. Exposed public keys are already publicly archived, available to any post-Q-Day attacker.

Addresses that have not yet exposed their public key remain protected until they initiate a transaction. However, recent research indicates that CRQCs could eventually break ECC-256 in a matter of minutes – potentially within Bitcoin’s 10-minute block time, enabling real-time “on-spend” attacks on otherwise protected addresses.

Smart contracts present an additional layer of risk. Smart contracts are self-executing code deployed immutably to a blockchain. They generally cannot be modified once deployed, unless they include a built-in, deliberate upgrade mechanism. Smart contracts that rely on ECDSA-based signatures for authorization may be exploited through quantum-derived private keys, allowing attackers to impersonate users and execute unauthorized transactions, with no ability to remediate retroactively. And many contracts designed to be upgradable rely on a proxy pattern in which a single, typically ECDSA-based administrator key allows for changes to the contract; if a quantum attacker derives that key, they can rewrite the contract’s logic.

Both Bitcoin and Ethereum are actively developing PQC migration strategies. Ethereum introduced a PQC roadmap in February 2026, targeting 2029 for full PQC protection. Bitcoin’s path is more constrained by its conservative governance model, with several proposals and an open-ended timeline.

Regulators already emphasize the importance of designing for CRQCs. In its guidelines on blockchain, the EDPB notes that “the possibility of technical advances such as cryptanalytically-relevant quantum computers, should be balanced with regard to the sensitivity and value of the data, and the risks to the data subject . . . . Such risk should be assessed in the design phase of the processing and should be part of the risk management process along the life cycle of the processing, including with periodic reassessment.”

From a legal perspective, quantum compromise of blockchain systems and smart contracts introduces familiar but unusually hard-to-contain risks: unauthorized transfers of digital assets, loss of confidentiality or control over wallets, and exploitation of application logic, all of which can trigger disputes, litigation and regulatory scrutiny. The key distinction is the limited ability to remediate, making loss allocation and recovery more complex than in traditional systems. These risks may also heighten diligence and disclosure obligations for organizations with significant blockchain exposure.

Data Protection Compliance and the Evolving Standard of Care

Independent of specific incident scenarios, the quantum risk landscape is reshaping the legal standard of care for information security. Various governmental bodies, including NIST, CISA, NSA, UK NCSC, EU NIS2 Cooperation Group and the Canadian CCS, have issued guidance on PQC migration and the deprecation of quantum-unsafe methods. This guidance will inform how courts and regulators conceptualize requirements to implement and maintain reasonable and appropriate security measures. They establish that the quantum threat is known, mitigations exist and preparation should begin now.

More recently, Executive Order 14,412, “Securing the Nation Against Advanced Cryptographic Attacks,” frames PQC migration as a current national cybersecurity priority, setting accelerated timelines for the transition of certain high-value federal assets and directing the development of a new requirement for federal contractors to be compliant with NIST PQC standards by the end of 2030.

Increasingly, regulators also are making clear that quantum risk should be considered throughout the data and software development life cycles, not just after incidents. For example, the EDPB’s recommendations on supplementary measures for cross-border data transfers expressly observe that quantum computing is likely to threaten public key algorithms in common use, and that data exporters should consider the risk of HNDL strategies. The EDPB concludes that quantum-unsafe encryption should only be considered an effective supplementary measure to safeguard cross-border data transfers if, on Q-Day, the decryption and processing of the transferred data would no longer infringe on the rights of data subjects.

Conclusion

The legal risks from quantum computing start now and will play out over the coming decades. They span a continuum: from HNDL exposure today to potential retrospective concerns and future incidents. Regulatory frameworks are beginning to engage with these issues, although they are far from settled. This creates both uncertainty and risk for organizations. But proactive organizations also have the opportunity to influence how governments and regulators approach the quantum landscape, and to preemptively establish legally defensible positions.

We help clients identify and assess the varied and emerging legal risks associated with quantum computing facing their organizations, and we welcome the opportunity to discuss how these issues may apply to your unique situation. In the next installment, we will cover concrete actions organizations should take now.

Our spring and early summer also highlighted a broader trend toward more targeted areas of regulation. States continued to expand oversight of the data broker ecosystem through new registration, reporting, and consumer rights requirements, reflecting growing scrutiny over the commercialization of personal information. At the same time, AI legislation is moving toward frameworks regulating specific AI use cases and areas of targeted risks, such as employment-related AI technologies and companion chatbots.

This quarterly update examines these developments and the broader trends that they signal: increased scrutiny of the use of sensitive data, growing accountability for secondary uses of personal information, an expanding patchwork of obligations for data brokers, and a shift toward risk-based AI governance. Together, these developments highlight the need for organizations to maintain adaptable compliance programs capable of responding to a complex and rapidly evolving regulatory landscape.

State Privacy Law Updates

Our Q1 State Privacy blog post eloquently previewed Oklahoma’s consumer privacy law and the Alabama Personal Data Protection Act, both of which remain on the horizon, with effective dates of January 1, 2027, and May 1, 2027, respectively. The Louisiana Data Privacy Act and the Vermont Data Privacy and Online Surveillance Act have since joined the ever-expanding U.S. state privacy law map, with their states becoming the 22nd and 23rd in the U.S. to adopt omnibus consumer privacy laws. While both laws share many features common to existing state privacy frameworks – including consumer rights, transparency obligations, and data protection assessment requirements – they also introduce unique provisions that warrant careful attention.

Louisiana’s law takes effect on January 1, 2027, and includes a 30-day cure period that will be in effect until July 31, 2027. Vermont’s law offers a longer runway for compliance, with an effective date of January 1, 2028, and a 60-day cure period that would remain in effect until June 30, 2029. Notably, Louisiana departs from the approach adopted by most other states when determining applicability of its privacy law. Rather than relying primarily on a consumer data processing threshold, this law incorporates a $25 million revenue threshold factor, mirroring a California-style revenue trigger in determining coverage.

Another interesting feature of both laws is the adoption of a requirement to obtain consumer consent before “selling” sensitive personal data, separate and apart from the common requirement to obtain consent for processing sensitive personal data – perhaps signaling a trend toward the stricter regulation of data monetization of sensitive data. In the case of Louisiana, this consent requirement applies to more limited entities that derive significant revenue based on the commercial sale of personal data, as opposed to Vermont’s broader application of this requirement, positioning Vermont as a leader of stronger consumer privacy rights in this space. In addition to its consent requirements, another notable feature is Vermont’s lack of a broad nonprofit exemption. As a result, Vermont joins the growing list of states (including Colorado, Delaware, Maryland, Minnesota, New Jersey, and Oregon) whose privacy laws limit or exclude exemptions toward nonprofits, signaling a broader trend toward narrowing traditional nonprofit carve-outs from state privacy laws.

Several other states had noteworthy amendments take effect on July 1, 2026, illustrating that legislatures continue to refine existing law. Maryland’s amendment (HB 0711) to the Maryland Online Data Privacy Act redefines sensitive data and implements a ban on personal data sales to immigration-enforcement government units, in addition to prior bans on selling sensitive data. Tennessee’s SB 1735 amended the Tennessee Information Protection Act, which tightened its definition of biometric data to no longer exclude “data generated from a photograph or video or audio recording.” Virginia’s Consumer Data Protection Act was amended (SB 338) to ban the sale of precise geolocation data. Notably, in Virginia, “sale” is defined to only constitute monetary consideration, unlike states that allow monetary or other valuable consideration. Finally, Connecticut’s amendment (SB 1295) to the Connecticut Data Privacy Act implemented multiple changes, including lower applicability thresholds, moving from 100,000 consumers to 35,000 consumers, and enhanced protections for minors, such as implementing an actual knowledge standard on controllers barring processing of a minor’s personal data for profiling. Connecticut’s governor also signed an amendment (SB 4) that includes data broker provisions, discussed below, in addition to requiring the commissioner of consumer protection to establish an accessible deletion mechanism program and banning surveillance pricing outside of a limited exception for insurance and financial institutions.

In consumer health data news, Vermont’s new law contains broad consumer health data provisions that apply to entities conducting business in Vermont or targeting Vermont residents without any minimum processing threshold, unlike the law’s general provisions. Meanwhile, in New York, the much-contested New York Health Information Privacy Act has been reintroduced and, as of June 2026, has passed both the New York Senate and Assembly as a revised bill (S.9269), following Governor Hochul’s veto of the original version in December 2025. While the revised bill has modified certain controversial provisions, if enacted, its regulation of non-HIPAA-covered health data would have a significant impact on the health tech industry and beyond.

Enforcement Shaping the State Privacy Landscape

On May 8, 2026, California regulators announced a $12.75 million settlement with an automaker and its connected vehicle services affiliate over allegations that they sold California consumers’ driving and geolocation data to data brokers. The settlement is the largest penalty under the CCPA to date. According to the complaint, the automaker collected and retained personal information from hundreds of thousands of its connected vehicle service users, including driving behavior and precise geolocation data. Precise geolocation data is considered sensitive under all state comprehensive privacy laws because it reveals detailed information about a consumer’s movements and activities. In the past year, this heightened sensitivity has resulted in states amending their laws to impose enhanced requirements or even outright prohibitions on the sale of consumers’ precise geolocation data.

Against this backdrop, California alleged that beginning in 2020 the automaker sold that sensitive information to data brokers developing driver-rating products for auto insurers, despite representing that driving and geolocation data would not be sold and that insurance-related disclosures would occur only at the consumer’s direction. The complaint alleged violations of several CCPA requirements, asserting that consumers were not informed of the sales, were not provided an effective opportunity to opt out, and were not given the right to limit the use and disclosure of their precise geolocation data before it was disclosed to a data broker. These allegations follow a series of CCPA enforcement actions targeting similar compliance failures.

Notably, California also framed the matter as a purpose limitation and data minimization case, alleging that consumers provided driving and geolocation data to obtain connected vehicle services –  not to support insurance-related products – and that the automaker retained and disclosed the personal information beyond what was necessary for those services. This theory is similar to the state’s prior enforcement action against a health information website publisher, where regulators alleged that consumers visited the website to access health-related content but in the course of doing so also had their personal information disclosed to advertising partners in a manner that exceeded reasonable expectations and the purposes for which the information was collected.

This settlement reflects a trend of heightened regulatory scrutiny of sensitive personal information and indicates regulators’ interest in reviewing whether secondary uses of personal information (e.g., advertising, analytics, monetization, AI training, or profiling) are consistent not only with the disclosed purposes for which personal information is collected but also with consumers’ reasonable expectations. For businesses, the key takeaway is that compliance requires more than just accurate disclosures and functional consumer rights mechanisms; businesses must be prepared to justify why certain personal information is collected, retained, and shared.

Data Brokers

In Q2 2026, both Connecticut (SB 4) and New Jersey (Bill A5328) enacted new data broker laws and Vermont (H211) modified its existing data broker law. This marks the first passage of new state data broker laws since 2024. The passage of new laws and recent amendments indicates that states continue to prioritize regulation of data brokers.

Notably, Connecticut’s expanded data broker law is the second law to require the regulator (in this case, Connecticut’s Department of Consumer Protection) to develop a mechanism that allows all consumers to exercise their right to opt out. Previously, California was the only state that required consumers be offered a singular opt-out mechanism; California’s mechanism – the Delete Request and Opt-out Platform – is live and registered data brokers will need to begin complying with requests on August 1, 2026.

New Jersey’s data broker law makes waves as being the first law to tie registration costs to the volume of information that is brokered. As a result, registration costs can range from $5,000 (those that broker up to 100,000 consumers’ information) to $1.5 million (those that broker more than 4.5 million consumers’ information). As a result, New Jersey’s law imposes the highest registration fee under any state data broker law; the second-highest state registration fee is California at $6,000. Unlike other data broker laws, New Jersey’s law imposes obligations on data collectors, which are businesses that sell personal information to data brokers. Unlike data brokers, which by definition do not have a relationship with the consumer, data collectors collect personal information directly from a consumer and sell that information to data brokers. Like data brokers, data collectors will also need to register. Both data brokers and data collectors will be required to provide certain information during registration, such as prior cybersecurity events, and are banned from selling or licensing sensitive data. While the law took effect immediately, the Office of Consumer Protection issued an alert to clarify that companies will not need to register or pay fees until the spring of 2027, which will coincide with the launch of the registry.

Vermont’s data broker law, which was originally enacted in 2018, underwent significant amendments. One of the most significant changes was the broadening of the definition of “brokered personal information”; previously, the statute provided enumerated elements. The amended definition copies California’s definition by specifying that a consumer must intend to interact with a business; otherwise, personal information a business sells about the consumer that is collected outside of that intentional interaction may still be considered brokered personal information even if the consumer is a customer of the business.

The 2026 Q2 developments demonstrate that regulators are still focused on the data broker ecosystem, with states adopting broader definitions, centralized consumer rights mechanisms, higher registration costs, and more expansive obligations that can reach businesses beyond traditional data brokers. Current data brokers, and companies whose activities may qualify them as data brokers, should keep a careful eye on new laws and potential enforcement.

AI

Q2 2026 marked a notable shift in how states are approaching AI regulation. In particular, Colorado significantly reshaped its approach through SB 26-189, which repealed and substantially revised the Colorado AI Act before its effective date. The revisions came after a year of heavy criticism from businesses, industry groups, and other stakeholders that the original requirements under the Colorado AI Act were difficult to operationalize and overly broad, capturing a wide range of commonplace AI uses. Comparatively, the state comprehensive privacy laws regulate automated decision-making only when it is used to make decisions producing legal or similarly significant effects; the original Colorado AI Act imposed obligations across a much broader category of “high risk” AI systems. The revised law abandons many of the broad obligations in favor of focusing more narrowly on consequential decisions involving automated decision-making technologies and emphasizes transparency, consumer notice, and meaningful human review.

In contrast, Connecticut enacted SB 5, one of the most sweeping AI laws passed to date. Rather than regulating AI generally, SB 5 targets specific AI use cases and risks, including automated decision-making technologies used to make consequential decisions, AI-generated or synthetic content, AI companion systems designed for minors, developers of certain frontier AI models, and other specified contexts.

Many of SB 5’s requirements will take effect on a staggered basis between October 2026 and January 2028. Beginning October 2026, providers of subscription-based AI products must provide consumers with disclosures regarding key subscription terms before enrollment or renewal and obtain written acknowledgment of those terms. During 2027, SB 5 imposes governance and reporting obligations on developers of frontier AI models, or AI foundation models trained using more than 100 septillion (10²⁶) computational operations. SB 5 requires that these select companies establish anonymous whistleblower reporting channels, investigate reports relating to catastrophic risks, implement corrective measures where appropriate, provide updates to reporting employees, and periodically report on such issues to company leadership. SB 5 was enacted subsequent to similar laws in New York (the RAISE Act) and California (the Transparency in Frontier Artificial Intelligence Act), which similarly require reports for transparency and safety incidence, governance requirements, and whistleblower protections.

SB 5 will also require that by 2027, AI companion systems implement safety protocols to identify and respond to expressions of self-harm, suicide, or violence; provide clear disclosures that users are interacting with AI; and incorporate additional protections for minors, including parental controls and restrictions on certain engagement-maximizing features. Similar laws have already been adopted in states such as California, New York, Oregon, and Washington, demonstrating a growing legislative focus on companion chatbot-specific harms.

In the employment context, SB 5 will require that by 2027, employers using automated employment-related decision technologies in hiring and other employment-related decisions must provide notice regarding the use of the technology, its purpose, the categories and sources of personal data analyzed, and other information concerning the system before using it to make or materially influence employment-related decisions. This approach resembles existing laws regulating AI in employment, including New York City Local Law 144, which requires bias audits and notice to candidates and employees before certain automated employment decision tools are used. Notably, Connecticut’s approach differs from New York City’s framework by focusing primarily on transparency regarding the use and operation of covered systems rather than mandating independent bias audits.

By January 2028, obligations related to synthetic or AI-generated content and online safety protection for minors will come into effect, completing SB 5’s phased implementation and reflecting a broader trend of existing AI provenance laws in California, Utah, and Washington that impose data provenance obligations on providers of generative AI systems. Collectively, these laws demonstrate a growing focus on synthetic media and content authenticity, with legislators increasingly favoring targeted transparency requirements intended to help consumers evaluate the origin and reliability of digital content.

States also continued integrating AI requirements into existing privacy laws. For example, amendments to the Connecticut Data Privacy Act now require controllers to disclose in their privacy notices whether they use personal data to train large language models. Notably, however, the amendment does not define either “train” or “large language model,” creating uncertainty regarding the scope of this disclosure obligation and how broadly it may apply.

Looking Ahead

The developments of Q2 2026 suggest that state privacy and AI regulation is moving into a more mature phase. Rather than introducing entirely new frameworks, states are refining existing laws, strengthening existing protections for sensitive data, imposing additional obligations on certain business models like data brokers, and addressing emerging technologies through targeted requirements. Enforcement is evolving as well. California’s record-setting $12.75 million CCPA settlement signals that regulators are looking beyond disclosures and consent mechanisms to examine whether data practices align with consumers’ reasonable expectations. As privacy laws mature and enforcement activity increases, organizations should expect greater scrutiny of sensitive data, secondary uses, and data sharing practices. Looking ahead, organizations should prepare for a regulatory environment that is increasingly interconnected across privacy, AI, and consumer protection. New state privacy laws, expanding data broker regimes, and targeted AI regulations are creating overlapping compliance obligations that require coordinated governance rather than siloed compliance efforts. Organizations that maintain ongoing oversight and adaptability with regard to their privacy programs and document the rationale behind these practices will be in the best position to manage ongoing regulatory change.

Although defendants have secured meaningful victories, the legal landscape remains far from settled. Plaintiffs are also adjusting their theories in response to recent decisions, and the battleground is increasingly shifting from broad legal principles to the details of a company’s website practices: what disclosures were provided, when consent was obtained, whether consent mechanisms worked as represented, and how opt-ins and opt-outs were implemented.

Key Developments

Courts Continue to Examine the Limits of Privacy-Based Injury

The Third Circuit recently affirmed the dismissal of a putative class action challenging a defendant’s use of session replay code. Plaintiffs alleged that the technology intercepted and recorded website communications in violation of privacy laws. The court found that plaintiffs lacked standing and observed that it would be difficult to establish “a de facto invasion of privacy” where a website had made no express promise not to collect user data.

The decision also includes an important cautionary note. Citing its prior precedent, the Third Circuit distinguished between a website’s failure to obtain consent and allegations that a company expressly represented it would not collect certain information but did so anyway. That distinction may become increasingly important as plaintiffs focus on alleged gaps between corporate disclosures and actual data practices.

The Standing Debate Persists

A federal court in New York recently underscored the continuing divide among courts addressing Article III standing in website tracking cases. The plaintiff alleged that the defendant used third-party trackers to collect visitors’ IP addresses and other data. Reviewing decisions from multiple districts, the court noted that similar allegations have produced different outcomes and that no single determinative allegation reconciles the split. The court nevertheless concluded that several of the plaintiff’s allegations plausibly alleged a concrete injury sufficient to survive a motion to dismiss.

The Ninth Circuit also recently certified for interlocutory appeal the question whether the unauthorized disclosure of IP addresses and similar identifiers constitutes concrete injury sufficient to confer Article III standing. In doing so, the court acknowledged the significant split among district courts within the circuit. The forthcoming decision could provide much-needed guidance on standing requirements in website tracking litigation and may influence the viability of these privacy claims in federal court.

Even when a defendant prevails on standing in federal court, plaintiffs may pursue the same underlying claims in state court. Companies should therefore consider the jurisdiction, assigned judge, and specific allegations before deciding whether to pursue a standing defense.

The Rise of Pre-Consent Tracking Claims

Recent defense victories have not slowed filings. Instead, plaintiffs are refining their pleadings to account for—and test the limits of—recent court decisions.

One emerging theory is that companies must obtain consent before any data interception occurs.

A recent federal court decision illustrates the potential traction of this theory. The plaintiff alleged that third-party cookies on the defendant’s website began collecting and transmitting detailed user data the moment she landed on the website—before she could reject non-essential cookies. According to the complaint, the data collection occurred without her consent and despite her later decision to reject non-essential cookies. At the motion-to-dismiss stage, the court held that the plaintiff’s selection was allegedly ineffective because the website had already collected, tracked, and transmitted her data before she was able to direct it not to do so.

Relatedly, some complaints now allege that companies continue transmitting data to third parties even after users opt out of tracking or data sharing. In one case, a federal court found that allegations that a company created an expectation that user data would not be collected—but then collected it anyway—were sufficient to plead injury.

Newer complaints are also challenging the accuracy of privacy policies themselves, arguing that even where consent is obtained, it may not be enforceable if the underlying disclosures are incomplete or inaccurate.

What This Means for Companies

In this environment, reducing litigation risk requires more than technical compliance with federal and state privacy laws. Companies should consider practical steps to align website practices, disclosures, and consent mechanisms, including:

• Review website and application technologies to understand what tracking tools are deployed, when they activate, what data they collect, and where that data is transmitted.
• Evaluate cookie banners and other consent tools to ensure that notices are clear, accurate, and aligned with actual website functionality.
• Test consent and opt-out mechanisms to confirm they operate as represented, including before and after a user makes a consent choice.

Here’s where things differ as the two regimes stand right now:

• Regulatory authorities: China’s framework is jointly administered by the CAC, MIIT and MPS, signaling a broader state enforcement role, though nominally there are testing agencies that will be stood up. The U.S. program is led by a single agency – the Federal Communications Commission (FCC) – and relies on a public-private administration model with a lead administrator, cybersecurity label administrators and accredited labs. The Cyber Trust Mark regime can be expected to be limited to devices that fall within the FCC’s jurisdiction (it excludes, for example, products otherwise regulated by the Food and Drug Administration or National Highway Traffic Safety Administration).
• Product scope: China’s measures apply to products with Internet connectivity, subject to a catalog of covered products issued in batches. The Cyber Trust Mark is focused on wireless consumer IoT products, with defined inclusions and exclusions under the FCC’s rules. Time will tell whether this will lead to a wide divergence between the cybersecurity posture of devices that communicate via wireless spectrum and those that do not, but for now it is possible to develop a device that communicates solely via wired means in order to avoid applicability of this regime.
• Label architecture: China uses a tiered model with three security levels – basic, enhanced and leading – represented by one-, two- and three-star labels. The U.S. program uses a single trust mark rather than multiple consumer-facing security tiers.
• Substantive benchmark: China’s model distinguishes among escalating levels of cybersecurity capability, including a top tier tied to advanced resistance testing. The U.S. model is built around baseline qualification against program criteria rather than a graduated rating system displayed to consumers. The relative scoring aspect of China’s regime, where a three-star-labeled product must exhibit controls on par with other similar products and a superlative posture relative to two-starred products, may prove difficult to administer against the backdrop of a fast-moving technology landscape. The average three-star device may not be a three-star device in three months; in the wake of a major cybersecurity incident, the bar may change.
• Testing model: Under China’s measures, one- and two-star products may be tested in-house or by qualified third-party labs, while three-star products require additional third-party penetration testing. In the U.S. program, conformity assessment is routed through accredited labs and administrative bodies under the FCC framework.
• Information disclosed on/through the label: China’s label is comparatively information-dense: It includes the manufacturer’s name, the model, the security level, the validity period, the lab’s name, referenced standards/technical documents and a filing information code that can surface the test report and conformity materials. The U.S. mark is paired with a QR code to a public registry containing additional cybersecurity information, emphasizing consumer-accessible disclosures rather than a tiered label face.
• Government filing versus registry model: China requires a formal filing/recordation process through a designated filing platform before the label may be used. The U.S. program centers on authorization to use the mark and a decentralized public registry linked through the QR code.
• Enforcement intensity: China’s final measures place heavier emphasis on supervision and post-market enforcement, including revocation, public announcements of violations, potential legal penalties and inclusion of misconduct in China’s national credit information sharing system. By contrast, the U.S. program is primarily a labeling and authorization regime overseen by the FCC, with compliance mechanisms tied to the label program rather than a broader cross-sector credit or enforcement system. With that said, the incorporation of the Cyber Trust Mark regime into federal procurement cycles may create compliance hooks that rely on the Federal Acquisition Regulations, Defense Federal Acquisition Regulation Supplement and False Claims Act, among other things.
• Reassessment and life cycle obligations: China expressly requires refiling when key technical parameters affecting cybersecurity change or when the label validity period expires. The U.S. program also emphasizes life cycle cybersecurity information (such as support periods and update practices), but the structure is oriented more around ongoing consumer disclosures and program compliance than a formal refiling regime of the Chinese type.
• Policy orientation: China’s measures reflect a combined consumer protection, industrial policy and state supervision approach, with explicit ties to national standards and administrative oversight. Outside the federal procurement context (note, for example, the Pennsylvania IT procurement policy preference!), the Cyber Trust Mark is framed more squarely as a consumer information and market incentive mechanism intended to encourage Security by Design and improve purchasing decisions.
• Implementation maturity: China’s final measures were issued in April, with an effective date of July 1, while the U.S. program’s rules were adopted in 2024 and the FCC has continued standing up administrators and implementation mechanisms into 2026.

That approach comes at a cost – one that is too often realized only when a regulator or a plaintiffs’ attorney comes calling.

The HIPAA Security Rule was not designed with a finish line in mind but rather was meant to be an ongoing security program designed to address ever-increasing cybersecurity threats. The drafters envisioned a framework that grows and evolves in parallel with the healthcare company’s systems, vendors, workforce and threat landscape. Healthcare companies that understand their cybersecurity programs as a process consistently find themselves in the best position to defend against the ever-increasing number of cybersecurity threats and, when necessary, to respond to regulators and plaintiffs’ attorneys who seek to highlight inadequacies in their security. 

The Project Trap

Projects are given budgets, timelines and deliverables. In the context of HIPAA compliance, healthcare companies conduct a security risk analysis, draft policies and train employees all before the end of a fiscal year. They complete the process and move on to the next project.

Herein lies the problem. While these activities are a great first step, they are not sufficient to maintain compliance with the HIPAA Security Rule. There is an assumption on the part of companies that once the project is completed, security is achieved and can then be maintained simply by doing nothing. It cannot.

Healthcare IT environments are not static. Threat actor tactics are not static. Best cybersecurity practices are not static. The environment is constantly evolving, and so must healthcare companies. Upgrades to electronic health records platforms, the introduction of new vendors and the acquisition of new clinical practices using legacy systems are just some of the common changes to a company’s environment that can impact the threat landscape. Changes to the company’s environment are on top of external factors that may change the threat landscape, such as ransomware groups pivoting to new attack techniques, new vulnerabilities or new methods to circumvent existing protections, such as multifactor authentication.

These developments render stale the security risk analysis that was “completed” 12 months ago. Healthcare companies that treat HIPAA security as a one-time project incur increasing risk as more time passes. As these risks accumulate over time, they will provide more opportunities for threat actors to exploit the systems and make it increasingly difficult to defend the sufficiency of the security program in response to inquiries by regulators and plaintiffs’ attorneys.

There is also a speed problem. The 2026 BakerHostetler Data Security Incident Response Report (2026 DSIR) shows that threat actors are moving faster than in prior years from the initial compromise to the data theft and/or encryption of the systems. This information emphasizes the need to ensure there are processes and tools in place to quickly identify any unauthorized access. The increasing speed of threat actors is just one example of how an organization’s analysis of the security risk level can change as threat actors change and improve their techniques.

What the Security Rule Actually Requires

The HIPAA Security Rule binds healthcare companies to ongoing initiatives.

HIPAA requires accurate and thorough analysis of the potential risks and vulnerabilities of the confidentiality, integrity and availability of electronic protected health information (ePHI). It is not a one-and-done activity. The expectation is that a company implements and maintains appropriate security measures. This means periodic evaluations. If a healthcare company ever faces an investigation, the Office for Civil Rights (OCR) will typically ask about the organization’s HIPAA security risk analyses and risk management plans; HIPAA policies and procedures, including effective and revision dates of these policies; and the records and copies of HIPAA security trainings. These investigations often happen following a data breach or a patient complaint to OCR. Organizations that ensure compliance before such investigations are in the best position to quickly and effectively respond to OCR, usually with no penalty.

Security Risk Analyses Are Effective Only When There Is Continuous Compliance

OCR has provided general guidance on what is required for a HIPAA security risk analysis but, despite the routine focus on these analyses, has not provided specific instruction on how they should be performed. OCR did, however, point to National Institute of Standards and Technology guidance focused on risk management as a base to use when performing a HIPAA security risk analysis.

The general steps when performing this type of risk analysis are:

• Step 1 – System Characterization
• Step 2 – Threat Identification
• Step 3 – Vulnerability Identification
• Step 4 – Risk Analysis
• Step 5 – Control Recommendations
• Step 6 – Results Documentation

Due to the fluid nature of companies, an accurate analysis of the threats and vulnerabilities faced by healthcare companies will require periodic analysis. Therefore, the first step is for healthcare companies to set up a regular cadence for their HIPAA security risk analysis. For many healthcare entities, the analysis is performed annually. However, in addition to this regular analysis, companies should perform a new, perhaps focused, analysis whenever a material change occurs in the IT environment. Material changes are those that may impact the types or level of risk to the organization. Examples of material changes are the introduction of new technology in the IT environment, hiring new vendors that handle ePHI, restructuring the workforce or the occurrence of a security incident. Depending on whether a change is material, the healthcare company may need to reassess only a portion of the environment, but this decision should be based on the specific change to the environment. Healthcare companies should maintain policies that define a material change and assign ownership to the personnel responsible for monitoring, recording and enacting a new security analysis based on the material change.

Following the security risk analysis, healthcare entities then use the identified threats and vulnerabilities as well as the controls in place to address and mitigate the risks in the form of a risk management plan. Each identified threat or vulnerability risk may be assigned a risk rating. Some risks will likely need to be addressed quickly, whereas other risks may require additional time and/or funding to address. Additionally, an organization may decide to accept a risk.

Under the HIPAA Security Rule, the set of controls that the healthcare entities plan to implement to reduce the identified risks is referred to as a risk management plan. Risk management plans should prioritize remediation steps, assign ownership of the actions and include timelines to complete the actions. Due to the nature of creating short-, intermediate- and long-term goals, this plan is an ongoing process. In addition, areas that are considered low risk at one time may be considered higher risk at another time due to changes internally in the environment or externally such as new technology or threat actor tactics.

Continuous monitoring is essential for ongoing compliance. Effective monitoring includes log reviews, vulnerability scanning, access control auditing, vendor security monitoring and tracking of workforce compliance with security policies. For example, without continuous monitoring of the threat landscape, it is easy to miss new tactics used by threat actors. According to the 2026 DSIR, threat actors are frequently moving from initial access to exfiltration without deploying encryption. As a result, relying on ransomware-style detection is not sufficient. Healthcare companies that have performed a more recent analysis have had the opportunity to review and assess this risk and create a risk mitigation plan to address it by, for example, tuning their threat detection tools for credential-based intrusion, lateral movement and unusual data transfer rather than the presence of ransomware.

Enforcement Risk

In addition to the security benefits of ongoing security monitoring, there is an increasing amount of enforcement risk for healthcare entities that do not implement such measures. OCR’s Risk Analysis Initiative penalizes healthcare companies that have not performed HIPAA risk analyses or have not adequately managed risk. OCR’s programmatic focus on the performance of these risk analyses and implementation of risk management plans emphasizes the need for healthcare entities and business associates to ensure they are regularly assessing and responding to the cybersecurity landscape.

State attorneys general are also filling enforcement gaps left by smaller federal agencies. Multiple attorneys general launched investigations into healthcare companies in 2025, often concurrent with or even following investigations closed by OCR. These investigations often resulted in multiple regulators asking for evidence that the legally required security controls were in place at the time of an incident.

Treating HIPAA security as an ongoing and active program rather than a completed project is the foundation of a defensible compliance posture. Healthcare companies and their vendors that commit to continuous risk analysis, monitoring and remediation are far better positioned to withstand scrutiny from regulators and plaintiffs’ attorneys alike. In our next article, we tackle another complex area of the HIPAA Security Rule – what “addressable” safeguards are and why addressable does not mean optional.

This post is part of a series on practical HIPAA Security Rule compliance. It draws on themes explored in “HIPAA at 21 Years of Compliance: Why the Security Rule May Be Entering a More Prescriptive Era,” published by BakerHostetler, and data from the 2026 DSIR.

These legacy networks – especially those managed by a third‑party IT vendor – linger in the now control of the acquiring entity longer than necessary after closing. When those networks are not tightly governed, clearly scoped from a security‑responsibility perspective and quickly migrated, they can become a significant cyber and compliance exposure for the acquiring health system.

The Risk: Lingering Networks

In today’s threat landscape, the most dangerous network may be not the one you built but the one you inherited.

Small physician practices typically operate with lean IT resources. Their networks may rely on aging hardware, minimal segmentation, shared credentials or security tools that differ dramatically from the acquiring enterprise’s standards. Once acquired, these environments may remain operational to support continuity of care, billing workflows or legacy electronic health record (EHR) access – sometimes for months or even years.

During this transition period, the legacy network may:

• Remain connected (directly or indirectly) to the acquiring enterprise network
• Continue handling electronic protected health information
• Be administered by a third‑party IT vendor with limited oversight
• Lack uniform monitoring, logging or incident response integration

Attackers increasingly target these environments either as a crime of opportunity or because they offer a path of least resistance into larger, better‑defended health systems with deeper pockets to extort.

Third‑Party IT Vendors: Responsibility Gaps Create Risk

Legacy environments are frequently managed by managed service providers (MSPs) that supported the physician practice prior to the acquisition. While those vendors may continue providing services post‑closing, responsibility for security is often poorly defined.

Common pitfalls include:

• Assumptions (or even contractual provisions) that the MSP is responsible for “security” without specifying the specific services or controls the MSP will manage
• Unclear ownership of endpoint protection, firewall management or identity governance
• No formalized escalation or incident response coordination with the health system
• Limited contractual visibility into how the vendor will manage the network or handle privileged access, its responsibilities for implementing specific controls or its liability in the event of a security incident

When a security incident occurs, these gaps matter. Health systems can find themselves accountable for breaches impacting systems they did not design, tools they do not manage and users they do not fully control.

Ambiguous contractual language often complicates accountability for breaches and notification obligations. Many MSPs make ambitious promises when pursuing physician practices as customers yet adopt a minimal role when security incidents arise. To mitigate risk in legacy environments, it is essential to establish explicit security responsibilities, define liability for failures and clarify breach response requirements. Still, health systems acquiring these networks may be reluctant to invest in improvements for infrastructure destined to be decommissioned – underscoring the importance of migrating and shutting down legacy systems swiftly.

Risk Management During the Transition Period

Acquisition does not eliminate risk – it changes who bears it. Until migration is complete, health systems should treat legacy networks as active, high‑risk environments requiring deliberate governance and oversight and – where a third-party IT vendor is involved – clearly defined contractual responsibilities and liability.

Effective risk management during this period includes:

• Treating the legacy network as its own risk domain, not an extension of the enterprise
• Clearly documenting who is responsible for each security control (monitoring, patching, access, backups)
• Reviewing and limiting administrative and service account access
• Implementing segmentation or isolation from the core enterprise network
• Ensuring that logging, alerting and incident reporting align with system‑wide standards

Even where a third‑party IT vendor remains involved, the health system must maintain visibility and understand accountability.

Why Speed Matters: Migrate and Decommission Quickly

The longer a legacy environment remains operational, the longer it remains vulnerable. Every additional day increases the risk that outdated configurations, unpatched systems or compromised credentials will be exploited.

Health systems often delay migration due to operational complexity, EHR transitions or resource constraints, but prolonged coexistence is a risk in and of itself. A defined migration road map should be established as early as possible, with clear timelines for:

• Data and application transition
• Identity and access consolidation
• Decommissioning of legacy infrastructure
• Termination or restructuring of third‑party IT access

The goal is not simply integration – it is risk reduction. Legacy networks should exist only as long as absolutely necessary and no longer.

A Strategic Opportunity, Not Just a Technical Challenge

While IT integration can feel like a post‑closing afterthought, it is increasingly a core component of healthcare risk management. Legacy networks are not just technical debt; they are legal, regulatory and reputational exposure.

Health systems that proactively manage legacy environments – by clearly allocating security responsibility, actively mitigating risk during transition and prioritizing rapid migration – are far better positioned to reduce breach risk and demonstrate diligence to regulators, insurers and patients.

This is the first in a series of installments examining quantum computing risk from a legal and compliance perspective. Future installments will address legal exposure under cybersecurity, privacy and data protection laws and practical steps organizations should take now.

This post is one part technical primer and one part technical lookahead. A baseline understanding of the underlying technology helps separate real risk from hype. To that end, this post covers several related topics:

• It first describes cryptography and its relevance to modern life. It also describes quantum computing, how it differs from classical computing and how it will impact the cryptographic landscape.
• This post then defines “Q-Day,” the day when present-day encryption systems fail us. It discusses how quantum computers bring us to Q-Day, when organizations should expect it to occur and what governments recommend organizations do to prepare for it.

Cryptography: The Infrastructure of Trust

Cryptography is the discipline of protecting information by mathematically transforming it from readable “plaintext” to unreadable “ciphertext” to ensure that only authorized recipients can access it. It is the invisible infrastructure underlying virtually every aspect of modern digital operations: from TLS/HTTPS connections to VPNs, user authentication, email encryption, code signing, digital certificates, electronic signatures and blockchain networks.

There are two broad categories of encryption relevant here:

First, symmetric cryptography uses a single, shared key. Like a shared password, anyone with the key can encrypt or decrypt data. Symmetric cryptography’s security benefits come from the shared key’s obscurity. If an attacker does not know the key, there is no clever mathematical method to derive it. If they want to break the encryption, they must look for a needle in a haystack by examining each piece of hay.

Advanced Encryption Standard (AES) is by far the most common symmetric algorithm. Other common symmetric algorithms include ChaCha, Twofish and Serpent. Symmetric encryption is fast and efficient, so it is commonly used to protect bulk data. It is used to protect both data at rest and data in transit once two systems establish a session by agreeing on a shared encryption key. Using a single shared key is risky. To mitigate risk, systems will briefly use asymmetric cryptography (discussed below) to transmit a temporary “session key.” Securing the initial transmission and limiting how long any individual shared key is used mitigates many of the underlying risks.

Second, asymmetric (public-key) cryptography is more like a locked mailbox: anyone can deliver encrypted information using a public key (the mail slot), but only those with the mailbox’s private key can read it. Asymmetric cryptography allows parties to communicate securely, including over insecure or public channels, without having previously shared a key.

To function, it must be easy to generate a public/private key pair – but infeasible to reverse the process and derive the private key from the public key. Modern systems achieve this using mathematical trapdoors: math problems that are easy to compute in one direction but extremely difficult or time-consuming to reverse.

The most widely deployed asymmetric algorithms are Rivest–Shamir–Adleman (RSA), which relies on the computational difficulty of factoring large integers to generate secure key pairs, and Elliptic Curve Cryptography (ECC), which relies on the difficulty of solving the elliptic curve discrete logarithm problem. These algorithms underpin the protocols (e.g., TLS, SSH, S/MIME, DNSSEC) and public key infrastructure (PKI) that make authenticated, encrypted communications and digital signatures possible at scale.

Computers: From Classical to Quantum

Classical computers include virtually all computers on earth, from phones to laptops, servers and supercomputers. They excel at many modern tasks. But because of how they process information, they have a hard time with problems that require searching through enormous numbers of possibilities.

Quantum computers leverage quantum mechanical phenomena like superposition, entanglement and interference across numerous qubits (quantum bits), to represent many possible states simultaneously. Unlike a classical bit, which is limited to a binary state – yes or no, off or on – qubits can explore multiple paths in parallel, highlighting correct answers and suppressing incorrect ones, rather than sequentially testing each possibility. Fully realized quantum computers will be able to solve computational problems that are intractable on any classical computer, and they are particularly well suited to solve cryptographic problems.

Quantum computers are not science fiction. They exist and work today. But today’s quantum computers lack the scale and stability to solve real-world problems and primarily reside in research laboratories.

The primary bottleneck to practical quantum computing is the extreme fragility of qubits. Even small disruptions, like stray cosmic rays or cooling system vibrations, can cause quantum information to vanish (a phenomenon known as decoherence), disrupting computation. To address this, researchers build logical qubits by bundling together hundreds or thousands of physical qubits, the actual atoms or superconducting loops that store information. This creates redundancy and allows for error correction. But this approach exacerbates other bottlenecks:

• Quantum computers need to be kept at near-absolute-zero temperatures to minimize thermal noise and prevent decoherence. But as the number of physical qubits grows, so does the thermal load.
• Quantum gates, the way quantum computers perform operations on qubits, increase in complexity as the number of underlying qubits grows. Each quantum gate is a carefully timed pulse of energy, and even tiny errors in timing, power or frequency can lead to gate errors (e.g., leaking and nudging a neighboring qubit) or decoherence.

Likely in part due to the complexity of the field, at time of writing, strikingly few compelling applications for quantum computers have emerged. There is exciting research in many areas, but there are also significant technical hurdles. Many computational problems do not map nicely to the specialized, interference-based operations required to extract a quantum advantage. Nevertheless, as quantum computers advance and become more widely available, it’s reasonable to expect further innovation. Some expected applications include optimization and material sciences research.

One field of computing, however, is widely expected to see significant impacts from quantum computing: cryptography.

Quantum Computing and Cryptography

The entire asymmetric cryptography ecosystem on which modern secure communication depends is potentially vulnerable to quantum computing. Asymmetric algorithms are at high risk, while symmetric algorithms face less dramatic vulnerabilities. There are two primary quantum algorithms of note:

• Shor’s algorithm presents a highly efficient solution to the otherwise intractable math problems at the heart of RSA (integer factorization) and ECC (discrete logarithm). It threatens to undermine asymmetric cryptography. The algorithm uses modular arithmetic to identify potential solutions, which can then be checked for correctness. Quantum computers perform this process exponentially faster than classical computers. A sufficiently powerful quantum computer running Shor’s algorithm would break RSA, ECC, Diffie-Hellman key exchange, and DSA/ECDSA digital signatures, eliminating their security benefits.
• Grover’s algorithm provides a more modest speedup for unstructured search problems, the problems at the heart of symmetric key encryption. This algorithm halves the search process by using heuristics to evaluate many key candidates simultaneously. Because the speedup is only quadratic, AES and other symmetric algorithms can maintain current security levels by doubling their key length. This represents a negligible processing increase for encryption and decryption. For example, against Grover’s algorithm, AES-128 would provide only 64-bit effective security, which is extremely weak. But a system could implement AES-256 to retain adequate security at 128 effective bits.

The Shifting Timeline

A cryptographically relevant quantum computer (CRQC) is a quantum computer capable of running Shor’s algorithm at the scale needed to break real-world asymmetric cryptographic systems. Existing quantum computers are still far too small and error-prone to do this. The critical question is: when will quantum computers be good enough?

Q-Day is what cryptography researchers have dubbed the answer to that question. Until recently, most expert estimates placed this threat somewhere in the range of 2035-2065. But that consensus is rapidly shifting forward. Researchers have made significant advancements in the scale and stability of quantum computers. And at the same time, researchers have made significant improvements upon Shor’s algorithm, reducing the number of qubits and quantum gates required. Thus, the gap is narrowing faster than expected from both sides: quantum computers are becoming stronger faster than expected, and the threshold for quantum computers to become cryptographically relevant is lower than expected. Present indications are that the pace of improvement is continuing to accelerate.

Major companies warn Q-Day could arrive in 2029. Earlier this year, Google published research demonstrating that breaking the 256-bit elliptic curve discrete logarithm problem – the basis of ECDSA, used in most TLS connections and every major blockchain network – could be accomplished with fewer than 500,000 physical qubits, representing a roughly 20-fold reduction from prior estimates. A further estimate for neutral-atom architecture quantum computers suggests that breaking ECC-256 may require as few as 10,000 qubits. Most recently, IBM has warned of quantum “moonshot attacks” on high-value targets as early as 2029, and leading technology companies have tightened their timelines to secure against quantum attacks.

In practice, Q-Day may unfold gradually as the technology diffuses from secret, slow and expensive government laboratories to eventual widespread commercial availability. The basic message, however, is clear: without adequate preparation, critical cryptographic systems will break almost simultaneously on Q-Day.

Important Timeline Caveats: Harvest Now, Decrypt Later; Secrecy

There are two other important considerations when making decisions based on the timeline to achieve cryptographically relevant quantum computers:

First, sophisticated adversaries (primarily select nation-state actors) are already exploiting the quantum threat using a Harvest Now, Decrypt Later (HNDL) strategy – collecting and storing vast troves of encrypted data for later decryption. For data with a long shelf life – health records, trade secrets, government communications and other data that may remain sensitive for decades – the threat is already present. We will address the legal risks presented by HNDL strategies in our subsequent posts.

Second, once quantum progress reaches a certain threshold, governments and other sophisticated actors may stop disclosing their true capabilities. At the end of last year, Scott Aaronson, a leading quantum computing researcher, observed, “[A]t some point, the people doing detailed estimates of how many physical qubits and gates it’ll take to break actually deployed cryptosystems using Shor’s algorithm are going to stop publishing those estimates, if for no other reason than the risk of giving too much information to adversaries. Indeed, for all we know, that point may have been passed already.” When Google researchers provided their new, lower estimates in April of this year, they published their research as a zero-knowledge proof, a cryptographic method that allows others to validate their findings without disclosing the actual attack vectors that make the lower estimates possible.

Post-Quantum Cryptography (PQC)

PQC – sometimes called quantum-resistant or quantum-safe cryptography – refers to cryptographic algorithms designed to be secure against both classical and quantum attacks. It achieves security through mathematical problems believed to be hard even for quantum computers, such as lattice-based problems, hash-based constructions and code-based problems. PQC protects data from attacks by both classical and quantum computers and is designed to run on classical computers. This is the distinguishing factor between PQC and quantum cryptography, which seeks to encrypt information using quantum mechanics and hardware.

In 2016, the U.S. National Institute of Standards and Technology (NIST) launched a global competition to standardize PQC, as it has done for AES, SHA and other cryptographic algorithms. After eight years of evaluation, NIST finalized its first three PQC standards in August 2024:

• FIPS 203 (“ML-KEM,” based on CRYSTALS-Kyber): the primary standard for general encryption and key encapsulation, used to establish shared secrets in protocols like TLS.
• FIPS 204 (“ML-DSA,” based on CRYSTALS-Dilithium): the primary standard for digital signatures.
• FIPS 205 (“SLH-DSA,” based on SPHINCS+): a secondary digital signature standard based on hash functions rather than lattices, providing algorithmic diversity as a backup.

A fourth standard, FIPS 206 – “FN-DSA,” based on FALCON – is still in development. And in March 2025, NIST selected HQC, a code-based algorithm, as a fifth backup algorithm for key encapsulation, providing diversification in case weaknesses are discovered in lattice-based schemes.

The NIST process has not been without setbacks. Most notably, in 2022, one of the finalists for standardization was broken by a classical attack. There have also been side-channel weaknesses in certain implementations of Kyber/ML-KEM and compatibility issues with legacy devices. Even a rigorous, multiyear evaluation process can miss vulnerabilities, and it remains to be seen whether the standardized algorithms will fall to classical or quantum attacks in the future. Successful migration to PQC requires a carefully planned approach with validated implementations and ongoing monitoring and flexibility for newly identified weaknesses.

PQC Migration Timeline

In November 2024, NIST released draft guidance urging the adoption of PQC standards now, while also establishing a formal transition roadmap:

• Deprecated by 2030: RSA, ECDSA, EdDSA, Diffie-Hellman, and ECDH at 112-bit security levels – i.e., RSA-2048, ECC P-256 – should no longer be used in new systems.
• Disallowed after 2035: All classical public-key algorithms should be prohibited.

EU guidance largely aligns. The June 2025 Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, developed by the NIS Cooperation Group with European Commission support, calls for critical infrastructure to complete PQC migration no later than end of 2030 and full migration of remaining systems by end of 2035.

In light of recent developments, however, these timelines may not be aggressive enough, and leading technology companies, including Google and Cloudflare, have set 2029 as internal targets to secure against cryptographically relevant quantum computers.

For any organization, the timeline ultimately depends on three factors: the timeline for the arrival of cryptographically relevant quantum computers, the time required to migrate to PQC, and the length of time for which encrypted data must remain secure. For most organizations, that means PQC migration efforts should begin now if not already underway. Nevertheless, a majority of all websites with TLS still use RSA-2048 and, where ECDSA or ECDH is used, P-224 is still in widespread use – despite looming deadlines.

Conclusion

The quantum threat to cryptography is structural, not speculative, and the timeline is compressing. We are monitoring quantum computing and cryptographic developments and are ready to help assess exposure and build mitigation strategies. In the next installment, we explore the legal and compliance implications of this exposure.

• OCR is expanding its Risk Analysis Initiative to include demonstration of compliance with the HIPAA Security Rule’s risk management requirement.
• Framework assessments, maturity reviews, and third-party certifications may be useful inputs, but are not a substitute for compliance with the Security Rule itself.
• OCR’s scrutiny will continue to focus on whether an organization documents and implements security measures sufficient to reduce identified risks and vulnerabilities to a reasonable and appropriate level.

Risk Analysis vs. Risk Management: OCR’s Core Points

In April 2026, the U.S. Department of Health and Human Services Office for Civil Rights (OCR) released “Risk Management Under the HIPAA Security Rule,” a YouTube presentation addressing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule’s risk management requirement. Although framed as educational outreach rather than regulatory guidance, the presentation nonetheless delivers insight into OCR’s Security Rule enforcement agenda.

The practical message is straightforward: OCR expects covered entities and business associates (i.e., regulated entities) to act on the results of the risk analysis and to demonstrate that those risks were/are being addressed through implemented safeguards.

Risk Identification Is Only the Beginning

The Security Rule treats the security risk analysis and risk management plan as separate but interdependent requirements. The risk analysis requirement obligates a covered entity or business associate to conduct an “accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information” (ePHI) held by a covered entity. Risk management, in turn, requires the entity to “[i]mplement security measures sufficient to reduce [identified] risks and vulnerabilities to a reasonable and appropriate level.”

Together, the security risk analysis and risk management plan (“SRA/RMP”) help make an entity “compromise ready.” A security controls assessment, standing alone, says little about risk if it is divorced from the systems, data flows, and operational dependencies that matter to the organization, whether it is a hospital with a vast ePHI footprint or a startup business associate. An interdependent SRA/RMP is more effective because the security risk analysis captures (1) how ePHI moves through an organization’s environment; (2) which processes are mission critical; (3) what threats are reasonably anticipated in that setting; and (4) whether existing safeguards sufficiently reduce those risks in practice. The corresponding risk management plan is a road map for the entity to systematically address the identified risks and plan the short-term and long-term resources needed for its implementation.

An integrated SRA/RMP is especially important for organizations managing complex ePHI asset inventories, legacy systems, acquired operations and/or multiyear enhancement road maps. As noted in the YouTube presentation, OCR views risk management not as the immediate elimination of every identified risk, but rather as evidence that the organization has prioritized risks in a reasoned way, documented those decisions, and tied planned security initiatives to the probability and potential impact of the risks to ePHI. In this way, the Security Rule’s flexible framework permits the consideration of factors such as the organization’s size, technical infrastructure, and budget – provided that flexibility is not used as a basis for avoiding the necessary expenditures on safeguards altogether.

NIST Alignment, Gap Assessments and Certifications

A related issue is the extent to which some regulated entities rely on cybersecurity framework assessments or certifications as proof of HIPAA compliance. OCR’s recent messaging underscores that such reliance can be a mistake. A National Institute of Standards and Technology (NIST) mapping exercise, International Organization for Standardization (ISO) review, or consultant-issued statement that an entity is “HIPAA compliant” may inform broader compliance efforts, but none of those outputs independently establishes Security Rule compliance. We have seen clients taken by surprise when an OCR investigation identifies security deficiencies after the client has paid for a NIST mapping exercise or obtained HITRUST certification, thinking it was not only sufficient for HIPAA compliance, but actually superior to it.

To be clear, OCR’s video message is not anti-framework; in fact, OCR permits entities to demonstrate the implementation of recognized security practices aligned with NIST or the 405(d) Health Industry Cybersecurity Practices as a way to mitigate penalties during an investigation. Rather, OCR is clarifying that these exercises, like conducting penetration testing, are useful inputs only to the extent they are integrated into an organization-specific process for identifying risks. As outlined in the YouTube presentation, and as reflected by our own experience with OCR, this process should include:

• Documented, reasoned remediation decisions
• The implementation of related safeguards
• A review of the effectiveness of those safeguards over time

Practical Takeaways – the SRA/RMP

Covered entities and business associates should treat the security risk analysis and risk management process as a continuing governance function rather than a one-time deliverable. That is the shift reflected in OCR’s recent messaging, and it is the point HIPAA regulated entities should take seriously.

For organizations seeking to bolster their own SRA/RMP process, they should:

• Ensure the security risk analysis is based on a comprehensive ePHI asset inventory.
• Confirm there is a documented process for prioritizing and remediating identified risks.
• Ensure remediation decisions are tied to likelihood/impact and implementation status.
• Review and update the risk management plan as technologies, threats, and operations change.

The BakerHostetler Healthcare Privacy and Compliance (HPC) team has guided thousands of HIPAA regulated entities through OCR investigations and provides practical, effective support in helping entities conduct and document their SRA/RMP. Please reach out to Kimi Gordy, HPC lead Lynn Sessions or your BakerHostetler attorney for more information.