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.

State Privacy Laws and Amendments

January 2026 marked another expansion of the U.S. state privacy law map, with the compliance bar continuing to rise. Three new comprehensive privacy laws became effective on January 1, 2026 – the Indiana Consumer Data Protection Act, the Kentucky Consumer Data Protection Act and the Rhode Island Data Transparency and Privacy Protection Act. Each closely follows the established state privacy law model and grants consumers core rights, including access, deletion, correction and opt-out rights. For companies already complying with other state consumer privacy laws, these new laws generally fit within existing compliance architectures, with some unique nuances (such as Rhode Island’s proactive requirement that companies disclose third parties they sell personal data to).

California remains a demanding jurisdiction. Amended California Consumer Privacy Act (CCPA) regulations took effect on January 1, 2026, refining compliance expectations and, in some cases, increasing operational complexity around privacy risk assessments, cybersecurity audits and automated decision-making. These changes coincide with the approaching launch of California’s centralized deletion mechanism for data brokers, reinforcing California’s role as both a substantive and enforcement bellwether.

The Maryland Online Data Privacy Act (MODPA) fully entered its enforcement phase as of April 1, 2026, following the expiration of a six‑month grace period. MODPA is among the nation’s strictest state privacy regimes, with substantive limits on personal data processing and reduced reliance on consent as a fallback, making Maryland a jurisdiction compliance teams should watch.

Several other states have refined their laws in ways that signal regulatory priorities. For example, effective January 1, 2026, Oregon amended its Consumer Privacy Act to prohibit the sale of precise geolocation data and the personal data of consumers under 16 in certain circumstances. Also in January, New Jersey enacted immediately effective amendments, expanding HIPAA‑related exemptions and the definition of de‑identified data.

Virginia’s governor has signed amendments to its Consumer Data Protection Act banning the sale (defined in that law as only for monetary consideration) of precise geolocation data, effective July 1, 2026. Kentucky also passed amendments that classify automatic content recognition data from smart TVs as sensitive data, with enforcement starting July 1, 2027, signaling heightened scrutiny of IoT and smart‑device analytics. Utah enacted targeted refinements, taking effect January 1, 2027, to the Utah Consumer Privacy Act to motor vehicle manufacturers and telematics providers regardless of traditional applicability thresholds.

March 2026 added Oklahoma to the comprehensive consumer privacy law map, although Oklahoma’s law does not take effect until January 1, 2027. Alabama soon followed. Signed on April 16, 2026, the Alabama Personal Data Protection Act takes effect May 1, 2027. Both laws closely align with existing state consumer privacy laws, granting residents the rights to access, correct and delete personal data, as well as to opt out of data sales and targeted advertising. For companies already complying with other state privacy laws, these additions do not introduce fundamentally new obligations, but they continue the steady expansion of multistate compliance expectations and reinforce the need for scalable, repeatable privacy programs.

Enforcement Shaping the State Privacy Landscape

Legislative activity was only part of the story in Q1. Enforcement actions during the quarter underscored that regulators are actively coordinating, increasingly assertive and focused on whether privacy rights function in practice rather than merely existing on paper. Across jurisdictions, regulators are converging on several enforcement priorities, including the protection of health data, location data and children’s and teens’ data, effective opt-out mechanisms, transparency around automated decision-making, and the monetization of sensitive data.

One of the clearest enforcement signals remains the expectation that opt-out rights be meaningful, low-friction and operative across devices and platforms. State regulators began coordinated investigations in late 2025 targeting companies that allegedly failed to honor universal opt-out preference signals, such as Global Privacy Control (GPC). By early 2026, at least a dozen state statutes required recognition of such signals. California, Colorado and Connecticut have each publicly emphasized that these signals must be honored consistently and without unnecessary friction. For companies, this means ensuring that websites, mobile apps and consent management platforms are properly configured to detect and process opt-out signals and that those mechanisms are tested end-to-end on a regular basis.

High‑profile enforcement actions continue to underscore this point. In parallel actions, California and federal regulators pursued a family entertainment and media conglomerate for alleged privacy and children’s data violations, resulting in a $2.75 million CCPA settlement related to honoring consumer rights requests (including GPC) across services and devices, and a separate $10 million civil penalty resolving Children’s Online Privacy Protection Act (COPPA) claims related to child‑directed content and data practices. Together, these actions reflect regulators’ willingness to tie technical opt‑out failures directly to monetary penalties, particularly where sensitive data is implicated.

Enforcement during Q1 also highlighted heightened scrutiny of how companies handle minors’ and student data. In March, the California Privacy Protection Agency announced a $1.1 million settlement with a youth sports media and ticketing platform for allegedly conditioning access to services on acceptance of tracking technologies, failing to provide compliant opt‑outs and failing to honor opt‑out preference signals. The agency emphasized that businesses cannot rely on industry opt‑out tools alone and must provide their own effective opt‑out mechanisms, particularly where student and youth data is involved.

As also reflected in various recent state-level amendments, regulators are treating precise geolocation and connected‑device data as high‑risk categories. In January, and consistent with trends we’ve been seeing at the state level, the Federal Trade Commission finalized a broad order against an automotive manufacturer over allegations that it collected and sold precise geolocation and driving behavior data without adequate disclosure or affirmative consumer consent. The order imposes long‑term restrictions on data sharing and mandates expanded consumer access, deletion and opt‑out rights, reinforcing that location data monetization will be closely scrutinized under unfair and deceptive practices theories, even outside comprehensive state privacy statutes.

Children’s and teens’ data protection also drove one of the most consequential enforcement and litigation developments of the quarter. In March, New Mexico secured a $375 million jury verdict against a social media company under the state’s consumer protection law, based on findings that the company misled consumers about the safety of its platforms and engaged in practices that endangered children. The verdict, one of the largest to date obtained by a state against a technology company, reflects a growing willingness by attorneys general to use existing consumer protection frameworks to challenge platform design and algorithmic features as well as representations about youth safety. That trend was reinforced the same month by a separate California jury verdict finding two social media companies liable for harms linked to the addictive designs of social media platforms and treating those platforms as defective products based on how their features were engineered to engage minors. Both companies have signaled their intent to appeal. Taken together, these cases indicate that regulators and courts are increasingly willing to look beyond content moderation and focus on product design and algorithmic engagement alongside the real‑world impacts of digital services on children and teens, significantly expanding enforcement and litigation risk for companies that serve or attract younger users.

Finally, enforcement attention expanded further into algorithmic decision‑making and pricing. In January, the New York Attorney General demanded extensive information from an online grocer regarding alleged algorithmic pricing practices, focusing on whether the company provided adequate disclosures about the use of personal data to affect prices under New York’s Algorithmic Pricing Disclosure Act. The inquiry highlights that algorithmic systems affecting consumers’ economic outcomes are rapidly becoming an enforcement priority, even where no dedicated AI statute is invoked.

Collectively, these actions reflect a clear enforcement shift toward testing operational privacy compliance. Regulators are examining whether opt‑out mechanisms function in practice, whether sensitive data use aligns with disclosures, and whether companies can demonstrate transparent, governable algorithmic systems across products and platforms.

App Age Assurance Laws

App store age assurance laws remain one of the more operationally complex privacy developments heading into mid‑2026. While much of the litigation posture remains unsettled, companies with consumer‑facing apps should not view these laws as theoretical.

Texas’ App Store Accountability Act was enjoined days before its January 1, 2026, effective date on First Amendment grounds and is currently on appeal. That decision has placed similar statutes under close judicial scrutiny, but it has not slowed legislative momentum.

Utah’s App Store Accountability Act is scheduled to take effect May 6, 2026, following a legal challenge and last‑minute legislative amendments addressing preinstalled apps, default safety settings and age‑verification flows. Importantly, those amendments defer substantive compliance obligations for app stores and developers until May 6, 2027. The amendments also eliminate enforcement authority by the Utah Attorney General while leaving a private right of action in place. Louisiana’s Online Protections for Minors law is scheduled for July 1, 2026, and California’s Digital Age Assurance Act is slated for January 1, 2027. In February 2026, Alabama became the latest state to adopt an app store accountability statute, extending common age‑verification, account categorization and parental consent requirements and also applying them to previously installed apps and existing accounts. Like California’s law, Alabama’s law takes effect January 1, 2027.

For private companies, these laws raise recurring issues, including determining whether particular apps or features are in scope, especially where minors may reasonably access them. Age‑verification and age‑estimation mechanisms themselves create sensitive data and data minimization concerns. Parental controls and teen‑specific defaults must be synchronized with state privacy rights and disclosures. Enforcement risk is unlikely to stay confined to app stores alone, particularly where developers, advertising practices or downstream data flows involving minors are implicated.

AI, Privacy and Emerging Best Practices

Q1 confirmed that AI governance is no longer separable from privacy compliance. In United States v. Heppner, for example, a federal court held that communications between a nonattorney employee and a public consumer AI tool were not privileged, focusing on how the tool was used and what the tool’s privacy notice explained to users about data uses and disclosures. Other courts have reached different conclusions on different facts, reinforcing that regulators and judges are scrutinizing transparency, notices, usage context and user expectations.

Although AI-specific legislation has encountered political headwinds, state regulators have made clear they will regulate AI through existing privacy, consumer protection, civil rights and antitrust laws. The Connecticut Attorney General’s February 2026 guidance explicitly emphasized this approach, warning that discrimination, deceptive practices and unlawful data use remain fully enforceable regardless of whether AI-specific statutes exist, particularly where consumers, children or essential services are affected.

AI compliance in 2026 resembles early-stage privacy compliance, with regulators moving from broad principles toward named risks, prohibited conduct and required governance documentation. Several state consumer privacy laws now include express rights related to profiling and automated decision-making. For companies, the takeaway is straightforward – if personal data is used to train models, power biometric systems or drive consequential decisions, regulators may ask not only whether models work but also whether consumer rights were honored, disclosures were accurate, opt-outs functioned, discriminatory effects were assessed and governance records exist.

Looking Ahead

Several significant requirements will take effect this summer, continuing the shift toward stricter oversight of minors’ data, automated processing, opt-out rights and compliance readiness. Amendments to the Connecticut Data Privacy Act will expand applicability thresholds, add to sensitive data definitions, enhance consumer automated decision-making rights and require new disclosures related to the use of personal data for training large language models. Utah’s Consumer Privacy Act will add a right to correct personal data and Arkansas’ Children and Teens’ Online Privacy Protection Act will impose COPPA-style obligations on companies collecting data from children and teens, including limits on targeted advertising and heightened consent requirements. Louisiana’s App Store Accountability Act is scheduled to take effect. Colorado’s delayed AI law may finally (or may not) come online with requirements tied to bias assessments, transparency and monitoring for discriminatory outcomes, although the Colorado Attorney General has in response to pending litigation signaled no intent to enforce the law until rulemaking is complete.

At a high level, any entity that wants to achieve CMMC certification should begin by answering the following questions:

• What level of CMMC will I need for opportunities in the next 24 months?
• Does my organization have a system security plan (SSP)?
• Does my organization currently follow any other security standards that could be used as a starting point?
• Do we have a data map showing the data flows, involved systems and third parties that receive information from my organization?
• What policies, procedures and training are currently in place?
• What types of documentation could my organization produce to evidence the implementation of the policies and procedures?

CMMC Level

Even if your organization does not yet have a contract with the Department of Defense (DoD) that requires a specific CMMC level, you can still estimate the level you may be required to meet for future opportunities. First, look at past contract terms to see if your organization received or created controlled unclassified information – information that will require CMMC Level 2 – or if your contract only involved federal contract information – information that will require CMMC Level 1. Second, review the required CMMC level in new contracts and solicitations that are similar to the type your organization would like to bid on in the future. This exercise will shed light on the CMMC level that the organization should work to achieve. Third, particularly if you are a subcontractor, discuss with your teaming partners and prime contractors the CMMC level they anticipate needing from your organization in the future.

The specific level your organization may need to achieve will be business-dependent. However, the DoD estimates that when CMMC is fully operational, the following number of certified contractors will be needed at each level:

See Ready or Not, CMMC Is Here: DoD Issues Final Rule Establishing Contract Clauses Implementing CMMC Program.

Do You Have an SSP?

An SSP functions as a guide to explain how an organization complies with required security contracts. More specifically, an SSP is a document that describes how an organization meets the security requirements for a system or how an organization plans to meet the requirements. The SSP describes the system boundary, the environment in which the system operates, how security requirements are implemented, and the relationships with or connections to other systems. See NIST SP 800-172.

In other words, the SSP describes how the organization is meeting the controls required by the applicable CMMC level. While there is rigidity in the controls that must be met, there is more flexibility in how to meet them. If you do not already have an SSP, work with your appropriate legal, information security and compliance team members to develop one that aligns with the appropriate anticipated CMMC level. While the exact process for developing an SSP will be specific to your organization, here are some key points to consider:

• If you already follow another security standard, start by assessing the overlap of controls so that you can leverage work that has already been accomplished.
• Understand the types of data you collect and process, the systems that touch that data, and any third parties that receive the data. This will help you better scope your CMMC obligations and may potentially allow you to keep portions of your environment out of scope for any assessment.
• The language used in the SSP matters and has legal ramifications. SSPs are representations that an organization is making regarding its security posture and compliance. As such, plan to include your legal stakeholders in the process of drafting and reviewing the SSP.
• Drafting the SSP will likely be an iterative process that needs clear coordination. It involves collecting data from across your organization, interviewing stakeholders, understanding and documenting evidence, and potentially coordinating with third parties such as cloud service providers.

There is no one-size-fits-all approach because every organization is different and will have a different starting point. Organizations should discuss where they are starting, the end goal and the parties (internally and externally) that should be involved in the process. And then, with that information in mind, map out a plan.

I Already Have an SSP; Now What?

Organizations that already have an SSP should work with the same stakeholders described above to review and, as needed, update the SSP to match the controls needed for the business’s goals. The review should assess whether the SSP’s representations are still accurate based on the organization’s current practices and ensure that the SSP addresses all required controls.

Wait! My Documentation Needs Its Own Documentation?!

Yes, the CMMC process involves a lot of documentation. The SSP is essentially the master document that helps steer your information security compliance program. The SSP will describe how the organization implements each control. But the SSP is just the starting point that will lead to a list of additional documents and actions that will be required to bring the organization into compliance with the target CMMC level. The next layer of documents are the policies and procedures. These policies and procedures will act as a part of the supporting documentation and evidence showing the implementation of the security measures described in the SSP.

The policies and procedures will cover a number of topics. When writing the SSP, organizations reference specific policies and procedures to show how the organization meets the specific controls. In some cases, a policy is explicitly required, while in other cases, having the policy in place is the best method to evidence the implementation of a control.

The SSP and the organization’s policies and procedures will work hand in hand to show exactly how the organization meets each of the required controls.

Relatedly, the workforce will need to be trained on the policies and procedures. Organizations with fully implemented programs will have trainings in place to ensure the workforce is aware of the requirements. CMMC also especially requires incident response training to ensure the workforce understands what to do if there is a potential security incident.

The extensive documentation required to create the compliance program is another reason it is critical to have someone who understands the requirements, considers the big picture and ensures that the right boxes are checked. There should be multiple reviews throughout this process to confirm that all documents align with each other and with how the organization operates in practice.

What Comes Next?

In an upcoming post, we will discuss additional evidence that an organization will need as it moves closer to the CMMC audit.

If your organization is considering CMMC certification, the process to assess what must be completed to pass the CMMC assessment should be started as soon as possible. Depending on where your organization is starting, there may be a significant amount of work to complete before it is ready for the audit. Every organization needs to start somewhere and there are many ways to meet the controls, but implementation takes time.

Starting the process as soon as possible is particularly important for organizations that have lines of business connected to the federal government. Without the required level of CMMC certification, organizations risk being excluded from future procurements that include CMMC requirements and may be left out of the supply chains for larger contracts.

Takeaways

Operators offering functional chatbots (i.e., not intended for companionship) should consider installing safeguards to prevent users from building an ongoing relationship with those chatbots. And operators offering companion-style chatbots should consider the following:

• Identify the contents and delivery mechanisms of mandatory user disclosures.
• Implement mandatory safeguards for input and output related to, promoting, or facilitating suicidal ideation and expressions of self-harm.
• Begin building technical and organizational infrastructure to collect data and report on suicide- and crisis-related referrals.
• Operators who receive minor user age information, or whose site or chatbot could reasonably be construed as directed toward minors, should safeguard users from sexual, emotionally, and financially manipulative content.

See our earlier post on the Washington Legislature’s 2026 technology agenda for further discussion of bills from the 2026 session and tips for in-house counsel.

Scope

HB 2225 recognizes AI systems with “human-like responses” and that can “sustain a relationship over multiple interactions” as “AI companion chatbots.” This legislature sought a narrow definition, evidenced by multiple exclusion categories emphasizing that outputs likely to generate emotional responses; open-ended companionship; discussions about mental health, self-harm, and sexually explicit conduct; maintained dialogue; and a sustained relationship across interactions are all central to determining whether a system is an AI companion.

Baseline protections

HB 2225 requires AI companion operators to provide certain safeguards for all users starting January 1, 2027.

AI companions must provide “clear and conspicuous disclosure” that their content is AI-generated. Users must receive this notification whenever they begin an interaction with an AI companion, and every three hours thereafter. The law doesn’t specify the nature, location, or exact contents of such disclosures. Accordingly, we recommend watching for executive, judicial, and industry guidance as the law evolves. Operators must also implement safeguards to prevent AI companions from undermining these disclosures or otherwise claiming to be human.

And, AI companions must introduce safeguards that (1) identify when users are expressing suicidal ideation or self-harm, (2) direct users to crisis resources such as suicide or crisis hotlines, and (3) implement “reasonable measures” to prevent the chatbot from generating content that facilitates or encourages self-harm. The notion of self-harm extends beyond traditional definitions – the law specifically includes eating disorders. So, operators should be aware of other less conventional definitions of self-harm, including psychological or emotional harm.

Operators must also publicize details about these safeguards and the number of crisis referral notifications issued in the prior year. It’s unclear whether operators should count crisis referral notifications made prior to the law’s effective date.

Additional protections for minors

HB 2225 introduces additional protections for AI companions directed at minors and for general-audience AI companions when the operator knows the user is a minor. Notably, the law does not create an affirmative duty to learn of or verify user age. However, the law does not define what constitutes knowledge. Under an expansive read, we think this could pull in, for example, minors who self-identify in an interaction; minors who indirectly reference their age in a user profile; or, on sites with social media functions, comments or reports that a user is a minor. But we expect courts will also see arguments advancing narrower interpretations.

Affected operators must provide hourly disclosure notifications, up from every three hours; implement safeguards to prevent AI companions from generating “sexually explicit content” or “suggestive dialogue”; and from using “manipulative engagement techniques” that would create or prolong an emotional relationship between the user and the AI companion.

HB 2225 provides a non-exhaustive set of examples of manipulative engagement techniques. The list includes: using emotional appeals to prompt minors to increase the frequency and length of their interactions; simulating a romantic bond with minors; simulating negative emotions in response to a minor’s attempts to end an interaction, reduce usage, or delete their account; leveraging the AI companion’s relationship with a minor to make financial solicitations; outputs designed to promote social isolation or emotional dependence on the AI companion; and outputs encouraging minors to withhold information from adults.

Because this list is non-exhaustive, we recommend taking a broader approach to AI protocols addressing these protections. The closer AI companion behavior or output gets to these categories, the riskier it is to permit it. This is particularly true over sustained interactions, where AI companions might employ borderline techniques multiple times.

Enforcement

RCW 19.86.093 provides a private right of action to enforce HB 2225. Operators that violate HB 2225 have performed an “unfair or deceptive act” and so violate RCW 19.86.020. Injured parties may seek injunctive relief, actual damages, and an increase to up to treble damages at the court’s discretion, capped at $25,000.

Sibling law comparison

California (enacted), New York (enacted), and Oregon’s legislature (awaiting governor signature) have each passed their own AI companion protections. Compared to these laws, Washington’s new law features the strongest protections for general audience users and minors alike. New York bill A6767 proposes amendments that we do not discuss in this post due to the bill’s infancy.

Scope: All four states define AI companions as systems that sustain a relationship over time, and contain business operation exclusions. California and Oregon also include video game and consumer electronic device exclusions, but only Washington carves out educational tools. These exclusions generally do not apply when chatbots exceed each carve-out’s tight functional bounds.

Disclosure: Both Washington and New York require operators to provide initial and recurring user notifications to all users. California and Oregon require only an initial disclosure — and only when a reasonable person would be misled about the chatbot’s nature. California requires an additional global disclosure that AI companions may not be suitable for some minors.

Self-harm: All four states require AI companion operators to institute measures to detect user input containing suicidal ideation or expressions of self-harm and, upon detection, to refer the user to crisis resources. Oregon further requires operators to “use clinical best practices and expertise” for “additional intervention” for users who continue to make such expressions even after crisis resource provision. Oregon and Washington require measures to prevent chatbots from generating content encouraging or facilitating suicide or self-harm.

California, Oregon, and Washington require operators to publish both these protocols and their crisis referral notification data for the prior year. California additionally requires operators to report this information directly to the Office of Suicide Prevention.

Minors: Of these laws, HB 2225 provides the most robust protections for minors. Only Washington requires protections for both known minors and minor-directed chatbot users. California protects only known minors, and Oregon protects only minors the operator knows of or has reason to believe are minors. New York has no such additional protections.

California’s protections do not measure up to Washington’s in either scope or weight. Californian operators need only refresh disclosures to minors every three hours and avoid generating visually sexually explicit material or “directly stating” the minor should engage in sexually explicit conduct.

Oregon takes after Washington. It provides similar examples of verboten content, requiring measures preventing chatbots from simulating emotional dependence, romantic connection, sentience, or humanity; from creating rewards systems to incentivize interacting with the chatbot; and from eliciting guilt or sympathy following a minor’s attempts to end an interaction. Oregon does not couch these as manipulative engagement techniques, unlike Washington. Like California, Oregon only requires a disclosure refresh for minors every three hours.

Enforcement: Like Washington, California and Oregon both provide a private right of action with injunctive relief and actual damages available. Rather than provide a discretionary increase, the two states compute damages as the greater of actual damages and $1,000 per violation. New York has adopted a different approach with no private right of action. Instead, New York’s Attorney General may seek injunctions plus a penalty of $15,000 per day of violations.

Historically, our data has reflected both continuity and change, fluctuating between radical shifts and the steady continuation of known risks. This year offers both—hence our title, “The Risk Remains (Mostly) the Same.” When we began analyzing matter data in December 2025, AI’s role in incidents appeared limited. However, as we approached our March 2026 publication date, we clearly passed a tipping point. AI is moving beyond serving as just an “enhancer” for phishing: it is moving toward more sophisticated social engineering support and automation, and we are now seeing the rise of “vibe hacking” and autonomous coordination between agentic AIs. This volatility is further compounded by the current geopolitical climate. Adjacent to the conflict in Iran, will we see an uptick in disruptive cyber activity—from state-aligned hacktivism to renewed threats against critical infrastructure and global supply chains?

We are likewise navigating a regulatory inflection point. With new AI mandates and privacy laws in the U.S. and EU moving from theory and guidance to active enforcement, the margin for error is disappearing. The risk landscape is dynamic, compounding, and increasingly structural—highlighted by the recent chipset vulnerabilities.

We have navigated emerging risks before, and we know there is no “magic bullet.” As EDR deployment matured and secured endpoints, attackers pivoted to identity-based access, drastically shortening the time from initial compromise to completion. While EDR remains essential, organizations now require additional strategies to address the enterprise risk created by AI with privileged rights to APIs and assets. Our competitive advantage remains our unique perspective. By managing incidents, litigation, and regulatory investigations across entities of all sizes, we provide the data-driven clarity needed to navigate this uncertainty. Whether you are deciding when to notify, choosing between vendors, or prioritizing compliance enhancements, we help you align your response with your specific risk appetite. Ultimately, the fundamentals still matter. Phishing has remained the leading cause of incidents for all 12 years of this report. The organizations that succeed in this landscape are those that execute the basics consistently and effectively. However, with regulators becoming more sophisticated—particularly regarding governance, risk assessments, and data retention—an enterprise-wide approach to risk has never been more critical.

We remain grateful for the strong relationships with our clients and our trusted external partners. I am immensely proud of the BakerHostetler team for the care and expertise that generate this report each year. We hope you find it insightful, use it as a road map, and invite you to reach out to any member of our DADM Practice Group with your questions.