This quarterly update provides a deep dive into recently enacted privacy legislation and key enforcement activity and looks ahead to what businesses should expect next.

State Privacy Law Amendments

Privacy law never seems to hold still. Several states enacted meaningful amendments to existing privacy laws this quarter, while previously enacted amendments took effect.

California lawmakers were active this quarter in passing a variety of amendments to the California Consumer Privacy Act (CCPA) and other state privacy laws; however, Gov. Gavin Newsom did not sign all the privacy bills presented to him.

First, and perhaps most crucially, California SB 690 will take effect Jan. 1, 2027, and will eliminate private claims brought pursuant to California Invasion of Privacy Act (CIPA) Section 638.51 (the law’s “pen register” and “trap and trace” provisions). The law has a two-year retroactive effect, meaning that any private claims brought pursuant to Section 638.51 alleging improper use of a pen register or trap and trace technology are invalid. While Newsom signed SB 690, he also issued a signing statement calling on the California Legislature to do more to fix the other provisions of CIPA next session, citing the need to clarify that the other sections of CIPA are not intended to apply to online tracking technologies such as cookies and pixels. In the meantime, businesses should remain vigilant with respect to controls and risk mitigation for tracking technologies and reevaluate litigation strategy for pending CIPA claims.

Second, California SB 923 was enacted this quarter and also will take effect Jan. 1, 2027. SB 923 expands the CCPA deletion right to cover personal information collected from sources other than the consumer themself. Previously, unlike most other state privacy laws, the CCPA’s deletion right applied only to personal information collected directly from the consumer. Thus, the change here mostly brings the CCPA in line with other states. SB 923 also requires online-only businesses to provide consumers with the option to submit deletion requests via both an email address and a web form.

Third, California AB 2561, also taking effect Jan. 1, 2027, prohibits operating systems and mobile applications from restoring privacy settings to their default settings without consent. This applies to location settings, opt-out configurations and any other privacy settings and will prohibit businesses from resetting settings to default even in the event of a software update.

One notable piece of legislation that did not become law this quarter is California AB 1542, which was vetoed by Newsom. AB 1542 would have imposed a categorical ban on the sale of sensitive personal information. In vetoing the bill, Newsom said it went “a step too far” and noted that California residents already have the right to limit the use and disclosure of their sensitive personal information. It will be worth watching whether this bill, or a version of it, is reintroduced in future sessions, particularly as sales of sensitive personal information are banned by privacy laws in some other states.

Although enacted in June, just before Q3, Delaware’s HB 380 is worth mentioning. The law will amend Delaware’s comprehensive privacy law, effective Jan. 1, 2027. Among the key updates, HB 380 lowers the law’s applicability thresholds, including covered businesses that process the personal data of more than 10,000 Delaware consumers. Additionally, HB 380 explicitly requires controllers to conduct due diligence on third parties to which personal data is disclosed and imposes new contractual obligations related to the disclosure of personal data to third parties. Further, HB 380 expands the existing Delaware right to access a list of categories of third parties to which personal data is disclosed – now granting consumers the right to access a list of specific third parties. HB 380 adds new risk assessment requirements and privacy rights related to profiling and automated decision-making. Finally, the amended law expands the definition of sensitive data to include national origin, physical health treatment or status and neural data generated by measuring an individual’s central nervous system, while also prohibiting the sale of sensitive data except under certain circumstances.

Also, in New Hampshire, HB 1460, effective Jan. 1, 2027, was enacted this quarter. This amendment to the New Hampshire Data Privacy Act will prohibit the sale of personal data of children under 13.

Finally, don’t forget that key amendments to Connecticut’s privacy law took effect July 1. Now in effect are Connecticut’s reduced applicability threshold (35,000 Connecticut consumers), consent requirements for processing sensitive data and engaging in targeted advertising directed at teens, additional privacy notice obligations related to AI, updated risk assessment requirements, new consumer rights and more.

AI Chatbot Laws

Two states passed AI chatbot laws in Q3 2026, with California and Hawaii enacting new laws governing these technologies. These measures include new disclosure, consumer protection and child safety requirements. California’s laws focus on both consumer-facing customer service chatbots and safeguards for children using AI companion chatbots, while Hawaii adopted a broader framework addressing AI companion chatbot disclosures and crisis response.

On Sept. 10, Newsom signed SB 1119, which requires operators of companion chatbots to perform and document a comprehensive risk assessment before making a new or substantially modified companion chatbot available to California residents. The risk assessment would evaluate the companion chatbot’s “covered harm,” which includes (1) the reasonably foreseeable physical or financial harm to a child, (2) the severe and reasonably foreseeable psychological or emotional harm to a reasonable child, (3) a highly offensive privacy intrusion, and (4) adverse discrimination. The law does not apply to chatbots that provide customer service or internal research; are integrated into video games and cannot discuss mental health, self-harm and sexually explicit conduct or maintain a dialogue unrelated to the game; or are smart speakers. The law provides a private right of action and allows a prosecutor to bring a civil action up to $5,000 per affected child for each negligent violation and up to $15,000 per affected child for each intentional violation. Most of the law’s substantive requirements take effect Jan. 1, 2027.

Newsom then signed AB 1609 on Sept. 28. AB 1609 applies to businesses generating more than $500 million in gross annual revenue and prohibits these businesses from representing that their customer service chatbot is a human. The law also requires a clear and conspicuous disclosure when a reasonable person interacting with a customer service chatbot is likely to believe it is a human. Covered businesses must also provide a method to connect a customer with a live customer service agent through commonly understood commands, prompts, menu selections or verbal requests. For online chatbot customer services and telephonic customer service platforms, covered businesses must make a good faith effort to not place the customer on hold for more than 15 minutes before connecting to a customer service agent and to ensure that cumulative hold/wait times do not exceed more than one hour total. AB 1609 goes into effect Jan. 1, 2027.

Lastly, Hawaii’s SB 3001, signed and effective July 14, establishes requirements for AI companion chatbots. When a reasonable person interacting with an AI companion chatbot could be led to believe they are interacting with a human, the operator must provide a clear and conspicuous notice indicating that the AI companion chatbot is AI and not human. Further, if the operator actually knows or is reasonably certain that a user is under 18, it must clearly and conspicuously provide this same disclosure either through a persistent visible disclaimer or at the beginning of each session, along with an hourly reminder. AI companion chatbot operators must also implement a protocol for the AI companion chatbot to respond to prompts regarding suicidal ideation or self-harm, including reasonable efforts to refer the user to crisis hotlines and services. Additionally, the operator must not provide users under 18 with rewards or points at unpredictable intervals with the intent of increasing engagement or include AI outputs that discourage the user from disengaging with the AI companion chatbot. Beginning Jan. 1, 2028, operators must submit annual reports to the Behavioral Health Administration of Hawaii’s Department of Health with (1) the number of times an operator issued its crisis intervention services provider referral, (2) the operator’s protocols to detect, remove and respond to user prompts regarding suicidal ideation or self-harm, and (3) the operator’s protocols to prohibit an AI companion’s response promoting suicidal ideation or actions or self-harm.

Children’s Protection Laws

New Jersey and California enacted new legislation to protect children’s personal data. In New Jersey, A4015 is set to become the New Jersey Kids Code Act, an age-appropriate design code that requires online businesses to design digital products and services with the safety, privacy and well-being of children in mind. The law will apply to online services operated by businesses that meet certain thresholds and that are reasonably likely to be accessed by a child (under 13) or a minor (aged 13-17). Similar to other age-appropriate design code laws, the New Jersey law requires covered businesses to configure settings to the highest level of privacy, avoid dark patterns and aggressive push notifications, minimize the collection and use of minors’ personal data, limit algorithmic recommendation engines, prevent compulsive use and provide controls to block, report and delete accounts, among other requirements.

Also in New Jersey, A5362 was introduced and would prohibit the sale of minors’ personal data, regardless of the provisions in the existing New Jersey Data Privacy Act. The bill would further require businesses, including both controllers and processors, to provide minors and their parents with the ability to request the deletion of personal data.

Finally, California’s SB 867 bans the manufacture and sale of toys designed for children under 16 that contain embedded AI chatbots until Jan. 1, 2031.

Enforcement Actions

Regulators continued to actively enforce privacy laws this quarter, paying special attention to data brokers, children’s data and sensitive data. In California, the California Privacy Protection Agency (CalPrivacy) announced data broker enforcement actions against two data broker companies. One was required to pay a $52,400 fine, while the other received a penalty of $36,400. Both enforcement actions alleged failure to register as a data broker pursuant to the Delete Act. Also, in its first enforcement under both the CCPA and the Delete Act, CalPrivacy issued a decision alleging both failure to timely register as a data broker under the Delete Act and requiring consumers to provide sensitive personal information, including partial Social Security numbers (SSN), before allowing them the ability to exercise their right to opt out of sales. The decision demonstrates that a partial SSN is still considered sensitive personal information under the CCPA and that requiring a partial SSN to honor an opt-out request will be considered unlawful because California law prohibits verification before honoring opt-out requests, and so requesting a partial SSN before honoring an opt-out request is neither reasonably necessary nor proportionate. Collectively, these actions demonstrate CalPrivacy’s continued focus on data broker registration and sensitive data processing practices.

Connecticut announced investigations into multiple companies relating to website tracking and alleged failures to protect children online. According to the Connecticut attorney general, one of the companies did not use technological tooling to monitor for underage users, relied on reactive reviews of reported or manually discovered content and conducted no audits or reviews of the effectiveness of its age determination processes. Further, it was alleged that the company advertises to children and provides “frictionless access to account creation and anonymity.” According to the Attorney General’s Office, the investigation was prompted by deficiencies in the company’s privacy notice and consumer rights mechanisms, including the failure to obtain consent before collecting sensitive data.

Further evidencing the regulatory focus on children’s privacy and online safety, Connecticut also issued an advisory letter to social media companies regarding youth privacy protections, warning of future enforcement. In the letter, the attorney general cited a focus on children’s data and online practices harmful to children, such as addictive feeds, push notifications and dark patterns.

Finally, the Florida attorney general filed a lawsuit against a popular streaming service alleging violations of Florida’s Digital Bill of Rights and unfair and deceptive acts and practices (UDAP) law. The suit alleges that the platform secretly records data about children’s usage despite marketing its “Kids Profiles” as secure, ad-free and surveillance-free. The complaint further alleges that children’s behavioral data was collected and shared with data brokers and ad networks without parental knowledge or consent. Under the UDAP law, Florida also alleges that the platform’s autoplay feature removes natural stopping points between episodes in an effort to manipulate children’s behavior and bypass parental screen-time controls.

These actions demonstrate regulators’ ongoing focus on children’s privacy and online safety, sensitive data and data brokers, all trends that we expect to continue in the next quarter.

Looking Ahead

Our Q1 and Q2 state privacy blog posts also provide a detailed overview of comprehensive privacy laws taking effect in 2027, including in Oklahoma, Alabama, Louisiana and Vermont. While these laws share much in common with existing U.S. comprehensive privacy frameworks, we recommend revisiting those posts to learn more about the unique provisions that may warrant extra attention.

Businesses should also closely monitor regulators’ growing focus on data brokers, third-party data sharing and privacy rights mechanisms. Throughout 2026, CalPrivacy continued its aggressive enforcement campaign against data brokers for alleged violations of the Delete Act, data broker registration obligations and privacy rights requirements. These actions signal that regulators are increasingly scrutinizing not only whether companies honor consumer rights but also how those rights are exercised in practice. As California’s Delete Request and Opt-Out Platform becomes operational and additional states continue adopting data broker laws, organizations should evaluate their data sharing ecosystems, vendor relationships, consumer request procedures and data minimization practices before enforcement expectations further mature.

Finally, the next quarter is likely to bring heightened scrutiny of children’s privacy, sensitive data, online tracking technologies and AI-driven profiling activities. Recent enforcement actions demonstrate regulators’ increasing willingness to challenge advertising practices, age-assurance measures, youth engagement and the processing of sensitive personal information. Privacy leaders should prioritize children’s privacy programs, vendor and adtech reviews, AI governance frameworks, sensitive data controls and privacy-by-design initiatives, as these areas appear most likely to attract regulatory attention and scrutiny in the coming months.

For decades, technology attorneys negotiated SaaS agreements around familiar concepts: customer data, service updates, documentation warranties, indemnities and liability caps. The rise of generative AI has not rendered those provisions obsolete. Instead, it has transformed their significance.

Many organizations are discovering that their AI governance challenges did not begin with an AI agreement. They began with a SaaS agreement signed years ago.

In this three-part series, we examine how AI is changing the practical operation of traditional SaaS contract provisions, the contractual terms that deserve renewed attention and the governance frameworks organizations need as AI-enabled functionality becomes embedded in everyday software products. Based on our presentation “Not Your Mama’s SaaS: Same Clauses. New Consequences,” given during Atlanta Technology Week 2026 at Render(ATL), we explore the legal and commercial issues that arise when familiar contractual language collides with rapidly evolving AI technologies.

That Legacy SaaS Agreement Is Risky in the AI Era

The biggest AI risk in your SaaS agreement may not be hiding in a clause that specifically calls out AI.

It may be hiding in a provision that your organization negotiated years ago.

Most legal teams evaluating AI risk begin by looking for terms such as “artificial intelligence,” “machine learning,” “training” or “large language models.” Increasingly, that approach misses the real issue. Many of the contractual provisions driving today’s AI risk were drafted years before generative AI entered the mainstream. The language has remained the same. The consequences have not.

A Critical Truth

Organizations should stop asking whether their contracts mention AI and start asking whether existing language already permits it.

Our Fact Pattern

Imagine arriving at work and discovering that your organization’s CRM vendor has released a new AI assistant.

The tool drafts customer communications, reviews support tickets, summarizes interactions and accesses information throughout the platform. The feature was activated as part of a routine product update.

No new agreement was negotiated. Procurement was not involved. Legal never reviewed the change. The vendor had previously provided a subprocessor notice, but that notice did not prompt a review of what activating the AI feature would mean for the organization’s data.

Yet overnight:

• A foundation model provider may now process company data.
• New categories of prompts and outputs now exist.
• New online terms may apply through incorporation-by-reference provisions.
• Data may be used in ways that were never contemplated when the contract was signed.

The governing agreement may be five years old. The technology is new, but the contractual provisions on which it relies remain the same. The question is whether its existing update provisions, data-use rights and incorporated terms authorize what the new feature actually does.

The Problem Is ‘Same Clause, New Consequence’

Traditional SaaS contracts contain provisions that appeared straightforward when software was largely deterministic. The problem now is that the clause hasn’t changed, but the consequence of the clause has.

Take a standard update clause, for example. Historically, a provision allowing a vendor to “modify or update the services” meant interface improvements, bug fixes or additional reports. Today, the same provision may authorize deployment of AI functionality that reads customer data and influences customer communications.

Similarly, de-identified data provisions once supported analytics and product development. In an AI environment, the same clause may become the contractual basis for training activities, model improvement or long-term retention of information.

Why Definitions Matter More Than Ever

Many AI contract negotiations focus on risk allocation. Equally important issues arise from definitions. Before evaluating warranties, indemnities and liability caps, legal teams need to understand what information those provisions cover.

The question is not simply whether customer data is protected. It is whether those protections also cover prompts, outputs and information derived from customer data.

Modern AI contract terms increasingly separate data into categories such as:

• Customer data
• Inputs or prompts
• Outputs
• Usage data
• Service data
• Aggregated or de-identified data
• An agreement may classify information derived from customer data as service data, usage data, or aggregated or de-identified data. If confidentiality, use restrictions and return-or-delete obligations apply only to customer data, those exclusions can create significant gaps. The question is not simply what the vendor calls the information but which protections and permissions follow it.

‘No Training’ Does Not Answer Every Data-Use Question

A common misconception when contracting for AI-enabled services is that a restriction on training resolves the data-use questions.

In practice, vendors often use data in several distinct ways, including:

• Base-model training
• Fine-tuning
• Evaluation and safety review
• Retrieval

Each activity creates different artifacts, retention concerns, ownership questions and deletion challenges. A restriction on “training” is only a starting point. Legal teams should distinguish base-model training, fine-tuning, evaluation and safety review from retrieval, which allows an AI system to draw on stored information when generating a response.

A clause stating that a vendor will not use customer data for “training” may not address the multiple ways data and an AI system can interact.  Effective drafting requires identifying precisely which activities are permitted, prohibited or subject to separate approval.

While retrieval is not itself model training, it is still important, as retrieval indexes and embeddings can create additional stores of customer information or representations derived from it. The agreement should address their permitted use, retention and deletion rather than assume that a no-training restriction resolves those questions.

The De-Identification Back Door

If there is one legacy provision that deserves renewed scrutiny, it is the de-identified data clause.

Many agreements permit vendors to use (and perhaps own) aggregated and de-identified data to improve products and services. These provisions have long supported analytics, benchmarking and product development. But the label “de-identified” does not establish what standard the vendor must meet or what uses the agreement permits. AI makes both questions more consequential. As discussed above, de-identified data often falls outside customer data and its deletion obligation. The agreement should separately address deletion of source data and the treatment of models developed using that data, rather than assume that a general deletion obligation resolves both. Moreover, where the clause also grants the vendor ownership, the vendor may own the de-identified dataset outright.

Legal teams should also review feedback provisions, product improvement clauses and usage analytics rights, including how those provisions permit de-identified data to be used or owned. A provision that seemed routine when signed may now carry rights far more valuable than the parties contemplated. 

Outputs Create New Questions and New Risks

Traditional SaaS agreements focused primarily on customer inputs and hosted data. AI requires equal attention to outputs.

Questions surrounding ownership, exclusivity, uniqueness and intellectual property protection are now central issues. Outputs may not be unique. Similar prompts can generate similar results for multiple customers. Some vendors expressly disclaim that outputs are protectable intellectual property at all.

At the same time, customers are frequently asked to provide broad warranties regarding everything they submit to AI systems, creating additional diligence obligations and risk allocation questions. This creates a contractual risk tension that must be resolved. The result is an asymmetry: The customer warrants its inputs, while the vendor may give no comparable assurance about outputs. In Part 2 of our series, we will address how to allocate for that risk.

Key Takeaways

One of the most important lessons from this new era of AI contracting is that the highest-risk provisions are not necessarily found in AI addenda or AI-specific terms. They are often found in familiar provisions, negotiated years ago and long treated as routine, that have now acquired new meaning.

For attorneys and procurement professionals, the challenge is not simply understanding AI. It is understanding how AI changes the practical meaning of contract language that already exists.

This brief moment captured both the promise and complexity of ambient AI. As discussed in the 2026 Data Security Incident Response (DSIR) Report, implementation of AI tools in healthcare has accelerated significantly in the past several years. For patients, adoption is most visible in the exam room, where ambient AI tools listen to, transcribe, and summarize clinical encounters in real time. For healthcare providers under relentless documentation pressure, the appeal is obvious. But as AI integrations increase, so do the legal, privacy, and security implications. Organizations deploying these tools must navigate state laws drafted long before this technology or use case existed, emerging AI regulations, and professional ethics obligations.

For the healthcare industry, ambient AI illustrates a broader DSIR Report theme. Emerging technologies do not eliminate traditional risk – they reshape and sometimes amplify it.

Key Takeaways

• Healthcare organizations should evaluate ambient AI through multiple lenses, including privacy, security, regulatory compliance, ethics, and patient trust.
• State recording laws may create encounter-specific notice and consent obligations that extend beyond traditional Health Insurance Portability and Accountability Act (HIPAA) requirements.
• Regulatory expectations increasingly emphasize transparency, accountability, and meaningful human review of AI-generated outputs.
• The organizations best positioned to leverage ambient AI are those that pair innovation with strong governance and patient-centered implementation.

What Is Ambient AI & Why Are Providers Adopting It?

Ambient AI tools are designed to reduce documentation burden by passively recording clinical encounters, transcribing conversations, and generating visit summaries that are incorporated into the electronic health record. Some tools go further, assisting with coding, billing, or surfacing diagnoses and treatment recommendations. Additionally, ambient AI tools can be manually turned on and off—like the one used by my doctor—while others are voice-activated such that they are always “on” but only record when they detect a conversation.

For clinicians, the value proposition is very compelling. Documentation fatigue remains a persistent operational and workforce challenge, and ambient tools offer more direct engagement with patients during visits, reduced after‑hours charting and burnout risk, and more standardized and complete clinical documentation.

Legal and Ethical Considerations

Many healthcare providers initially approach ambient AI as a HIPAA compliance exercise, focusing on business associate agreements, security controls, and permissible uses of protected health information. While those issues remain important, the risk landscape is broader than HIPAA.

State Recording Laws

State recording statutes (aka eavesdropping or electronic surveillance laws) present one of the most immediate compliance issues for ambient AI deployment. Because these tools record private, in‑person conversations, they trigger consent obligations that vary significantly from state to state.

States generally fall into three categories:

• One‑party consent states, where only one participant in the conversation must consent to recording (here, the doctor).
• All‑party consent states, where every individual in the room – the doctor, the patient and any other person such as a nurse or a patient’s family member – must consent.
• Hybrid states, where the consent rule depends on whether the communication is electronic or in person.

Depending on the state, implicit consent, such as when an individual receives clear notice of a recording and voluntarily continues the conversation, is sufficient. Other states may require a more express verbal or written agreement. In the healthcare setting, organizations frequently rely on a combination of signage, patient intake materials, and/or verbal disclosures. However, because state recording laws were enacted long before the advent of ambient AI, questions remain regarding the duration and scope of any consent obtained.

For healthcare providers, the primary challenge is frequency of consent: state recording laws generally require notice or consent before or at the start of a recording. Because these statutes often refer to each “communication” or “conversation” in the singular, the notice/consent obligation may attach to each individual encounter, and not to the broader patient-provider relationship. As ambient AI becomes more visible, plaintiffs and regulators are questioning whether healthcare organizations are relying too heavily on one-time, generalized disclosures.

Informed consent is also a concern: a patient agreeing today to the use of ambient AI at a dermatology appointment may not understand the extent of that consent or want the same tool to listen in on a gynecology exam, which could present consent issues if both providers are within the same health system. Thinking critically about the varying sensitivities of the patient’s care spectrum, and how to operationalize renewing consent discussions, are essential aspects of ambient AI use in the care setting.

State AI Laws

States are increasingly enacting AI‑focused laws that emphasize disclosure, human oversight, and accountability, particularly where AI influences consequential decisions such as healthcare treatment or access to services. Most of these laws only require disclosure of AI use (as opposed to disclosure and consent). Other common themes include requiring providers to review the output generated by AI tools or exempting those that do; prohibiting the use of AI tools for certain types of care like mental and behavioral health; requiring disclaimer language on patient/consumer-facing communications that include AI-generated outputs; and outlining special considerations for “high risk” AI systems and/or those that may cause bias.

Ethics

Healthcare settings are unique environments with a central focus on trust, transparency, and respect for patient autonomy. As a result, legal compliance alone may not be sufficient to satisfy stakeholder expectations surrounding AI use. Even where applicable law permits recording with minimal formality, healthcare organizations should consider whether additional disclosures or consent practices are necessary to preserve confidence in the patient-provider relationship. Guidance from professional organizations and accrediting bodies continues to reflect broader ethical principles. The American Medical Association, The Joint Commission, and state-level associations and medical boards have consistently emphasized that AI should support, not displace, clinical judgment – and patients should not be left guessing about the role AI plays in their care or medical record.

In practice, this dilemma has translated into various emerging best practices such as proactively disclosing ambient AI use even in one‑party consent states, addressing patient questions and allowing them to decline participation where feasible, and requiring licensed clinicians to review, edit, and approve AI‑generated notes.

Where To Start – Practical Takeaways for Healthcare Organizations

Ambient AI can deliver meaningful benefits, but only when accompanied by thoughtful governance, appropriate oversight, and patient-centered implementation. As state regulators, professional organizations, and even patients continue to focus on the responsible use of AI in healthcare, organizations should consider the following foundational steps:

• Develop an AI governance program that establishes clear accountability for evaluating, approving, deploying, and monitoring AI-enabled technologies. The program should be led by a multidisciplinary team, incorporating representatives from compliance, privacy, information security, legal, and clinical operations. The program should address risk assessments, vendor review, acceptable use standards, human oversight requirements, change management procedures, and ongoing monitoring of AI performance and regulatory developments.
• Inventory ambient AI tools alongside all other clinical, operational, and patient‑facing AI. As highlighted in the DSIR Report, organizations should not overlook so-called shadow AI – unapproved or inadequately governed AI tools that may already be in use by workforce members. A comprehensive inventory should identify where AI is deployed, what data it processes, applicable vendors and sub-processors, and the risks associated with each use case.
• Standardize encounter‑level disclosure and consent practices, accounting for state law variability and ethical expectations. Healthcare organizations should treat ambient AI as a patient-facing activity rather than a purely internal documentation tool and build encounter-level disclosures, such as through room signage, check-in workflows, or clinical scripts.
• Enforce human review requirements so that AI-generated outputs never substitute for licensed clinical judgment. Ambient AI should be viewed as a tool that assists clinicians, not as a mechanism for delegating clinical decision-making; clinicians remain responsible for reviewing, validating, and approving AI-generated outputs before they become part of the medical record or influence patient care decisions.
• Train workforce members on the appropriate use of ambient AI. Clinicians and staff should understand the capabilities and limitations of AI tools, applicable disclosure and consent requirements, documentation expectations, escalation procedures, and organizational policies governing AI use.

The exam room will remain a human space. Ambient AI can support that goal by reducing administrative drag and improving focus on care. Realizing those benefits, however, requires more than technical implementation; it also requires embedding the principles of trust, transparency, and accountability into the design and governance of these technologies from the outset.

Cryptographic migrations can be slow, complex and expensive, and the timeline for the quantum threat is compressing faster than most had anticipated. With newly formalized post-quantum standards and regulatory guidance, including migration roadmaps, the time for orderly preparation is now.  

Organizational Quantum Readiness

The following foundational steps are appropriate for organizations with material dependence on cryptography, which includes most organizations that rely on public-key cryptography to secure sensitive customer, employee or business data or sensitive transactions:

• Appoint a post-quantum cryptography (PQC) program owner. Migration to PQC is a long-horizon, cross-functional initiative spanning IT, security, legal, compliance and procurement. It calls for an identifiable owner with executive support. This does not need to be a dedicated role, but it should be someone’s responsibility. Appointing an individual to this role will not only help drive the work forward but also demonstrate to regulators, boards and other stakeholders that the organization has committed resources to this issue.
• Conduct a quantum risk assessment. Assess your organization’s overall quantum exposure. The assessment will help your organization prioritize quantum readiness projects against each other and relative to the organization’s greater goals. Consider questions such as:
  • What types of data does the organization hold or transmit, and for how long must that data remain confidential?
  • Has the organization experienced past data incidents involving encrypted data or intercepted communications?
  • Does the organization rely on blockchain or smart contract technology?
  • What are the organization’s most sensitive systems, and what cryptography protects them, especially public-key algorithms?
• Build a cryptographic inventory. Identify every system, application, device and service in your environment that uses public-key cryptography – RSA, ECC, Diffie-Hellman, ECDH, ECDSA – for any purpose, including encryption, authentication, digital signatures, key exchanges, certificates and code signing. Include cryptography embedded in third-party products and services. The Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA) and National Institute of Standards and Technology (NIST) have all identified this inventory as the necessary first step; without it, you cannot prioritize. For critical systems, develop a cryptographic bill of materials (CBOM) – a structured inventory of every cryptographic component, algorithm and key length in use, analogous to a software bill of materials (SBOM).
• Develop a quantum readiness roadmap. Map your migration priorities against both regulatory, government (e.g., NIST) and industry (e.g., Google, Cloudflare) timelines. Prioritize systems by comparing the time required to migrate, the period for which affected data must remain protected and the anticipated quantum-threat horizon, including Harvest Now, Decrypt Later exposure. Include performance and interoperability testing, staged deployment and rollback planning before production migration.
• Engage vendors and service providers. Most quantum exposure tends to run through third-party systems: cloud providers, SaaS platforms, security tools, hardware vendors and certificate authorities. Map your vendor relationships against your cryptographic inventory and begin asking about their PQC roadmaps. For new procurement, begin incorporating PQC readiness requirements into vendor evaluation criteria and contract terms.
• Plan for cryptographic agility. Design systems to support multiple cryptographic algorithms, with the ability to swap them without full system replacement. Cryptographic agility – the ability to substitute algorithms as standards evolve – is the insurance policy against future vulnerabilities in newly standardized PQC algorithms. During the transition period, consider hybrid approaches that combine classical and PQC algorithms in parallel where appropriate.
• Begin deploying available PQC protections. NIST’s standards (FIPS 203, 204, 205) are finalized and being integrated into major platforms. Organizations do not need to wait and should enable these protections where feasible, according to their roadmaps.

Additional Steps for Technology Companies

Organizations that develop software, hardware, connected products or cryptography-dependent services face quantum risk not only as an internal security issue but also as a matter of product security and supply chain responsibility, with PQC obligations that extend beyond protecting their own internal systems.

For these types of organizations, key steps include:

• Treat PQC as a product feature, not just an internal control. For technology companies, cryptography choices shape product durability, customer risk and legal exposure. Customers, particularly enterprise and government customers, are beginning to evaluate products based on their ability to remain secure over the full data confidentiality period. PQC readiness thus increasingly functions as a product feature, procurement criterion and trust signal, not merely a backend security enhancement.
• Assess exposure across the product lifecycle. Long‑lived products – including embedded devices, medical devices, industrial control systems, enterprise appliances and IoT hardware – present heightened quantum risk because cryptographic weaknesses may not be practically remediable post‑deployment. Organizations should pay particular attention to cryptographic algorithms hard-coded into hardware or firmware and assess whether PQC migration can be achieved by software or firmware update or whether product replacement is necessary.
• Map PQC responsibilities within the shared responsibility model. Cloud service providers should carefully evaluate where responsibility for cryptographic controls sits between the provider and the customer. Where a provider controls the cryptographic stack, the provider ordinarily bears primary technical responsibility for PQC readiness. Where customers control cryptographic implementation, providers should ensure their platforms support PQC‑capable configurations and encourage customers to enable them, including by making PQC the secure default.
• Align product roadmaps with emerging procurement criteria. Government and critical‑infrastructure customers are beginning to incorporate PQC expectations into procurement criteria. CISA’s quantum‑safe product categorization efforts, CNSA 2.0 requirements for government systems, and parallel initiatives in other industries and jurisdictions signal a shift toward market access consequences for products that lag behind anticipated PQC timelines.
• Design for cryptographic agility. As above, given the novelty of standardized PQC algorithms and the likelihood of future refinements, products should be architected to support cryptographic agility. Hybrid approaches that pair classical and PQC algorithms can manage near‑term risk as standards mature.

Steps for Legal Departments

In-house counsel will play an important role in guiding and enabling organizational quantum readiness programs by translating post-quantum security requirements into governance, managing supply chain exposure and aligning technical processes with evolving legal and regulatory expectations.

Counsel must navigate not just quantum risk but also regulatory expectations. Although quantum computing risk is fairly universal, legislatures and regulators may express their quantum readiness expectations through jurisdictionally and sectorally limited frameworks. Expectations may vary based on differences in regulatory mandate, risk tolerance and enforcement posture, leading to differences in expected timelines and prescriptiveness for risk mitigation and consequences for delayed or insufficient action.

In addition to supporting the above quantum readiness activities, in-house counsel should consider the following steps:

• Compliance posture. Confirm that organizational quantum readiness programs are defensible against evolving legal and regulatory expectations. This includes tracking developments across cybersecurity authorities and relevant regulators, assessing how published roadmaps and guidance influence the applicable standard of care, and documenting rationale where organizational timelines or technical constraints diverge from published expectations. As with other emerging cyber risks, regulatory alignment is not static and should be revisited as standards mature and guidance evolves.
• Legislative and regulatory monitoring. Assign responsibility for tracking PQC developments across the jurisdictions where the company operates. PQC will increasingly be required by law, regulation and contract. This is a fast-moving area; multiple jurisdictions have already published material guidance or initiated rulemaking processes, and the future only holds more.
• Past incident review. Work with privacy counsel and information security teams to determine whether the organization needs a process to evaluate past incidents that were assessed as low risk because the data was encrypted. Monitor regulatory authorities’ approach in this space and, where indicated, consider proactive engagement with relevant authorities before the question becomes urgent.
• Vendor review. Review key vendor agreements – particularly cloud, SaaS and security service agreements – for cryptographic requirements, security warranties and notification obligations. Consider whether PQC readiness language should be added to standard vendor contract templates, RFP templates and vendor due diligence processes, and support vendor negotiations.
• Litigation and regulatory risk assessment. Assess whether use of legacy cryptography in specific high-risk applications creates regulatory risk or litigation exposure under negligence, product liability or contractual theories.
• Board and audit committee reporting. For many organizations, quantum risk may be significant enough to warrant inclusion in information security risk reporting to the board and audit committee. Consider developing a quantum risk briefing that accurately characterizes the timeline, identifies the organization’s most significant exposures and describes the migration program.
• Cyber insurance. Quantum risk is starting to appear in cyber insurance underwriting. Insurers are beginning to ask about PQC migration plans and could impose exclusions or higher premiums for organizations without demonstrable progress. Review policy terms for any exclusions relevant to encryption failures or quantum events and provide accurate disclosure of your current posture where appropriate.
• Product liability, warranties and representations. Work with product and engineering teams to evaluate the liability implications of long-lived hardware or software. Ensure marketing claims around security, encryption and product durability accurately reflect actual post-quantum capabilities.
• Readiness for customer, regulator and litigant scrutiny. As awareness of quantum risk increases, companies – especially technology companies – should expect questions about whether product design choices appropriately considered long‑term cryptographic risk. Internal documentation of design decisions, migration constraints and roadmap assumptions can be critical in responding to regulatory inquiries, customer audits and, ultimately, litigation premised on foreseeable cryptographic obsolescence.

Conclusion

The quantum threat is real. Industry standards and regulatory roadmaps have been published. The organizations that will be best positioned – legally, operationally and competitively – for the arrival of Q-Day are those that treat PQC migration as a structured program starting now.

We help clients globally and across sectors navigate quantum readiness and build legally defensible programs. This includes helping clients operationalize their quantum programs through key initiatives such as quantum risk assessments and cryptographic inventories, product and platform design, vendor and supply chain risk management, and litigation readiness.

In Europe, the Stop Killing Games movement has attempted to rally EU and UK legislators to address video game consumer protection issues as the industry continues to transform. Notably in June, the European Commission determined it cannot require a game to remain playable ​after the publisher decides to no longer support it. Instead, the Commission stated that it will “initiate an exchange with the video game industry and consumer representatives with the aim to draw up an industry code of conduct on managing video games’ ‘end of life.’”

As currently drafted, California’s Protect Our Games Act would apply to games first available for purchase or released for purchase on or after Jan. 1, 2027. Before a game operator sunsets services necessary for “ordinary use” of a game, the game operators will have to provide a prior 60-day notice to consumers as well as an alternate version of, a patch or update to, or a refund for the game, as provided. “Ordinary use” is currently defined to mean the “purchaser’s ability to use the core features of a digital game, consistent with the reasonable expectations of a purchaser based on how the digital game was advertised, marketed, or otherwise described by the digital game operator at the time of purchase.”

These consumer protections echo similar sentiments from the “freedom to tinker” movement, which aims to provide consumers with the right to repair, modify and improve the technological devices they own.

Under the Act as currently drafted, if an operator ceases to provide services necessary for the ordinary use of the digital game, the operator is prohibited from selling, leasing or otherwise distributing a version of the game that cannot be used by a purchaser independent of services controlled by the operator. For example, games that require the player to access an online server supported by the operator that are later deprecated cannot be republished as a new version unless the new version does not require access to such online servers. This is likely to help combat recent practices in the industry that involve shutting down live-serviced games only to quickly repackage the game as a remaster to charge the same community of players a second time for access to the same game.

As currently drafted, there will be no private right of action under the Act, and actions for relief may be prosecuted exclusively in a civil action by the California attorney general or by any district attorney.

We’ve also addressed similar issues before in our blogs California AB-2426: The Ephemeral Nature of In-Game Assets and Designing the ‘Buy’ Button: Clearer Disclosures, Fewer Lawsuits.

While the future of these policy movements is unclear, what is certain is that a focus on consumer protection in the digital space, including video games, is increasing.

BakerHostetler’s attorneys who are well-versed on interactive entertainment and video games work together across areas of law, including advertising, intellectual property, regulatory response and consumer protection, to address these cutting-edge policy initiatives. Where a video game developer and publisher cannot rely on explicit statutory requirements, we help determine best practices to mitigate risk. We continue to monitor the California Protect Our Games Act to see if it will gain more traction, considering that Aug. 31 is the last day for each house to pass bills and the legislature does not reconvene until January.

Alabama’s, Louisiana’s and Utah’s laws only apply to phones or “general-purpose” tablets. Similarly, California’s law only applies to computers, mobile devices and any other general-purpose computing devices.

The scope of the Texas law, the App Store Accountability Act, however, is far broader and may be interpreted to include certain video game consoles.

The Texas law applies to “mobile devices,” defined as “portable, wireless electronic devices, including a tablet or smartphone, capable of transmitting, receiving, processing, and storing information wirelessly that runs an operating system designed to manage hardware resources and perform common services for software applications on handheld electronic devices.”

Unlike the laws of the other states, the Texas law is not explicitly limited to general-purpose devices. To distinguish between a general-purpose device and a different type of device, courts have interpreted the term “general-purpose device” to mean a device that is designed to accomplish varying tasks and support different kinds of applications, rather than a device that is limited to a specific function. For example, the court in Aristocrat Techs. Austl. Pty Ltd. v. Int’l Game Tech., 521 F.3d 1328, 1333 (Fed. Cir. 2008), reasoned, “[A] general purpose computer ‘in effect becomes a special purpose computer once it is programmed to perform particular functions pursuant to instructions from program software.’” (quoting WMS Gaming, Inc. v. Int’l Game Tech., 184 F.3d 1339, 1348 (Fed. Cir. 1999)).

The Texas law lists tablets and smartphones as examples of devices that are in scope, leaving the law open to apply to other types of portable, wireless electronic devices, such as those designed specifically for video gaming purposes. 

Portable gaming consoles that use an operating system to function, are capable of processing information wirelessly, and perform common services for software applications (such as through an app and game store) could be game for enforcement under the Texas app store age assurance law.

Texas law outlines how laws should be construed, including that “if a word is connected with and used with reference to a particular trade or subject matter or is used as a word of art, the word shall have the meaning given by experts in the particular trade, subject matter, or art,” and “in interpreting a statute, a court shall diligently attempt to ascertain legislative intent and shall consider at all times the old law, the evil, and the remedy.”

It remains to be seen if the words used in the law, such as the definition of “mobile device,” will be further interpreted by experts, but the history of the law illuminates the scope of the intent. In the law’s analysis, the author and sponsors stated, “Growing concerns regarding the rise of social media and its pervasiveness in the lives of children and teens leave parents in the position of grasping for the best ways to protect their children. Unlike brick and mortar stores which must verify a consumer’s age before the purchase of age-restricted products such as alcohol and cigarettes, minors are currently able to navigate through the digital world without such parameters.” This intention was not revised through the law’s drafting and eventual enrollment. “Digital world” is quite broad, while the example of “social media” is narrower. That said, we note that Texas has a social media law specific to minors, the Securing Children Online through Parental Empowerment Act, which does not explicitly exempt video games (unlike other state social media laws) and even includes “video games” as part of the law’s prescribed joint committee study on the effects of media on minors.

As to enforcement, while a preliminary injunction initially prevented the law from being enforced, this injunction was recently lifted, permitting the Texas attorney general to move forward with enforcement. The challengers to the law asked the Supreme Court, through an emergency application, to reinstate the injunction until the Fifth Circuit could decide the case. The Supreme Court declined the requests in unsigned, single-sentence orders that did not address the law’s merits or constitutional issues.

While the Texas attorney general has yet to file an enforcement action under the law, video game console operators should evaluate how the Texas law may apply to their console’s app and game store. BakerHostetler’s attorneys focused on interactive entertainment and video games continue to monitor these laws, not just for app developers that design games for mobile devices but also for video game console operators.

For more, see our An App Developer’s Guide to App Store Age-Assurance Laws.

Key Provisions

• If signed, SB 690 would eliminate private lawsuits alleging website-based “pen register” and “trap-and-trace” claims, i.e., those that are based on the mere transmission of IP addresses or other transactional data, under California Penal Code Section 638.51.
• For businesses that have received demand letters or are already defending lawsuits premised on routine website tracking technology – such as cookies, pixels and analytics tools – SB 690 would offer relief from certain types of claims asserted under the CIPA.
• The bill would apply retroactively to pending claims in actions commenced within two years before its operative date, which is expected to be Jan. 1, 2027.
• SB 690 includes a severability clause, so if a provision is invalidated, the remainder of the act will remain in effect. That provision may prove important because plaintiffs’ firms are already preparing constitutional challenges to the bill’s retroactive application.

Limitations

Notably, SB 690 does not eliminate the California attorney general’s ability to bring claims under Section 638.51, and the bill leaves Section 631 untouched. Thus, plaintiffs can still bring a private right of action for the alleged interception of the content of communications.

Anticipating the passage of SB 690, plaintiffs have increasingly asserted claims under Section 631 and the Federal Wiretapping Act – presumably to avoid the retroactive provisions of SB 690. Thus, in practice, it is likely that SB 690 will shrink one category of claims yet leave plaintiffs undeterred.

Recommended Next Steps

• Keep an eye on whether Gov. Newsom signs SB 690. He has until Sept. 30 to sign.
• Review any pending Section 635.81 demand letters, suits or claims commenced within two years before the bill’s operative date
• Continue comprehensive reviews of analytics technology on your website and mobile apps to ensure you know what information is collected, when it is collected, whether it goes to third parties and whether your disclosures accurately describe what is happening. Also confirm your data collection practices comply with the California Consumer Privacy Act and any other industry-specific regulations or other privacy requirements.
• Continue evaluating your potential exposure arising from analytics technology under Section 631 and the Federal Wiretap Act.

“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.