Section 5 of the Federal Trade Commission Act, in its modern form codified at 15 U.S.C. § 45, prohibits "unfair or deceptive acts or practices in or affecting commerce." For most of the statute's history, the cybersecurity enforcement work the FTC did under Section 5 was deception cases: a company said in its privacy policy that it encrypted data, did not encrypt data, and got sued for misrepresentation. That deception theory continues to be the easier case for the agency to bring and the easier for defendants to defend against, because the conduct turns on what the company said publicly. The more consequential development of the last several years has been the unfairness theory, in which the FTC alleges that a company's failure to implement reasonable security measures is itself an unfair practice — independent of any public misrepresentation — and which now functions as a de facto software-security regulator for any company that meets the FTC's jurisdictional thresholds.
The unfairness theory under Section 5(n) requires the agency to show that the practice causes or is likely to cause substantial injury to consumers that is not reasonably avoidable by consumers themselves and is not outweighed by countervailing benefits to consumers or competition. The FTC has applied this framework to software-security failures with increasing precision since the LabMD litigation cleared procedural hurdles, and the recent cycle of enforcement actions — Drizly, the SolarWinds civil complaint, Henry Schein — is filling in what "reasonable security" looks like in the software supply chain context. This post walks through what that doctrine has become.
What does the FTC's "reasonable security" framework actually require?
The FTC has consistently declined to publish a prescriptive checklist of required security controls, on the stated rationale that what is reasonable depends on the size and complexity of the business, the sensitivity of the data, and the cost and availability of mitigations. In practice the agency has built up the framework through consent orders, and reading those orders together produces something close to a working standard. The recurring elements include written information security programs with senior-leadership accountability, asset inventories that include software components and not just hardware, vulnerability and patch management programs with documented timelines, identity and access management with multi-factor authentication for administrative access, encryption of sensitive data in transit and at rest, employee training, incident response planning with tested playbooks, third-party risk management for vendors and service providers, and independent biennial assessments by qualified third parties.
The Drizly consent order from October 2022 was the first to name the CEO personally as a respondent, on the theory that James Cory Rellas, as the CEO, was personally responsible for the company's security failures and had to carry obligations to his next employer. The order required Drizly to implement an information security program and to destroy data it had collected unnecessarily. The CEO-naming feature has been used selectively since (it does not appear in every consent order), but it reframed the conversation about executive accountability for security and gave the agency a precedent it can point to when it wants to.
The Henry Schein matter, settled in early 2025, involved a dental practice management software vendor whose security failures led to ransomware exposure across thousands of dental practices. The consent order is interesting because the harms flowed to downstream customers (the dental practices and ultimately their patients), and the FTC argued that the software vendor's failure to implement reasonable security in its product was an unfair practice as to those downstream parties. That is a supply-chain theory: the software vendor's security obligations run not only to its direct customers but to the downstream users whose data flows through the product.
How is the SolarWinds civil case (re)shaping the doctrine?
The SolarWinds civil action filed by the Securities and Exchange Commission in October 2023 is technically not an FTC matter, but it has shaped FTC enforcement thinking in two ways. The first is procedural: the SEC alleged that SolarWinds and its CISO made materially misleading statements about cybersecurity practices, and the federal court's July 2024 ruling dismissing most of the claims but allowing the misrepresentation-of-a-specific-public-security-statement claim to proceed set guardrails on how aggressive a regulator can be about characterizing internal security debate as fraud. The FTC has internalized that ruling in its own pleading practice, focusing on conduct that fails to meet reasonable security rather than on public statements that turned out to be optimistic.
The second is substantive: the SolarWinds complaint described in detail the engineering failures (weak credential hygiene on the build pipeline, lack of build-system isolation, lack of code-signing controls) that allowed the SUNBURST backdoor to be inserted into Orion updates. Those engineering details, presented in a publicly filed complaint by a federal regulator, have become reference points for what regulators expect from any software vendor running a build pipeline that produces customer-distributed binaries. The FTC has not (yet) brought an action explicitly tied to a build-pipeline compromise, but the doctrinal infrastructure is now in place.
The SolarWinds case is also notable for what it did not do: the SEC did not allege that SolarWinds was strictly liable for the SUNBURST compromise itself, only that the company had failed to disclose known security weaknesses adequately. That restraint — separating the question of whether security controls were sufficient to prevent a compromise from the question of whether the company had to tell investors about its security posture — is mirrored in the FTC's approach. The FTC has consistently said it does not require perfect security; it requires reasonable security.
What does this mean for software vendors specifically?
The clearest signal from the recent enforcement cycle is that software-vendor security failures create FTC exposure to downstream users, not just to direct customers. A SaaS company whose product is used by thousands of small businesses to manage their own customer data has security obligations to those small businesses' customers, on the FTC's theory. That obligation is mediated by the software vendor's product design, vulnerability management, and incident response posture, and the FTC has been willing to allege unfairness on the basis of any of those.
For software vendors operating in regulated downstream industries (healthcare, financial services, education), the FTC's enforcement complements sector-specific regulators. The agency has settled multiple matters in coordination with state attorneys general and sector regulators, and the trend in 2025 has been toward parallel enforcement rather than exclusive jurisdiction. A software vendor whose product handles healthcare data can face FTC action under Section 5, OCR action under HIPAA (if the vendor is a business associate), and state AG action under state UDAP statutes, for the same underlying conduct.
The practical implication for software vendors is that the floor for "reasonable security" rises with the sensitivity of the data the product handles and with the scale of downstream users affected. A vendor processing payment data for a single SMB is in a different posture than a vendor processing payment data for ten thousand merchants. The FTC has used scale as an aggravating factor in its complaints, and consent orders have correspondingly demanded more sophisticated programs from larger vendors.
How should programs respond in 2026?
Programs that want to stay ahead of FTC exposure should be running their security work through a documented information-security program that maps onto the elements the agency has consistently identified in consent orders. The mapping does not have to be a NIST CSF mapping (the agency has accepted multiple frameworks) but it does have to be coherent, written down, owned by an accountable executive, and reviewed at least annually. The biennial third-party assessment language in many consent orders has become an expected practice — even pre-order — for vendors operating at scale.
For supply-chain risk specifically, the program needs to cover both upstream (the open-source and third-party components the vendor consumes) and downstream (the customers and customers-of-customers the vendor serves). Inventories of upstream dependencies, vulnerability management timelines tied to those inventories, and evidence of patching against known-exploited vulnerabilities are now table-stakes evidence. The Henry Schein matter showed that the agency will look at whether the vendor's product itself created downstream exposure, so product security review — not just IT security review — has to be in scope.
How Safeguard Helps
Safeguard gives security programs the production-grade evidence base that FTC-style enforcement increasingly assumes is in place. The platform maintains continuous SBOMs as the canonical software-component inventory, runs vulnerability management on a timeline-evidenced basis (so you can show the agency that you patched a KEV-listed CVE within your stated SLA), and generates the audit-ready records that biennial third-party assessments depend on. Griffin AI maps your engineering posture onto the recurring elements of FTC consent orders, surfaces gaps before they become enforcement narrative, and drafts the kind of WISP language that holds up under regulatory review. Policy gates in Safeguard enforce supply-chain hygiene at ingestion and at deployment, producing the kind of automated, evidenced controls that consent orders increasingly require. TPRM workflows collect attestation from your suppliers and produce a defensible vendor-risk record that the FTC has signaled it expects mature software vendors to maintain.