The Federal Trade Commission's enforcement playbook has shifted. What began with Section 5 "unfair or deceptive" orders against individual vendors now reaches into software supply chains, third-party identity providers, and the vendors whose telephone-based social engineering surfaces routinely lead to material breaches. The 2023 MGM Resorts incident — acknowledged in MGM's September 8, 2023 Form 8-K and analyzed publicly by Mandiant and Okta — made clear that the blast radius of a help-desk compromise can reach casino floors, hotel key systems, and point-of-sale terminals. The FTC's follow-on theory of harm turns this into a software-procurement problem, not just an identity one.
This piece is written for security engineers and compliance leaders who need to translate FTC posture into engineering work. The short version: vendors will be required to prove, with artifacts, that their software and their subprocessors meet specific controls. Buyers will be required to verify those artifacts before onboarding. Neither side can keep relying on questionnaires.
What does the FTC's post-MGM posture actually require?
The FTC has not issued an "MGM rule." It has, however, stacked up orders that collectively create a de facto standard for how companies must govern software acquired from third parties. The 2023 Drizly order, the 2024 Blackbaud order revisions, and the Commission's May 2024 updates to the Safeguards Rule for non-bank financial institutions all push in the same direction: covered entities must maintain an inventory of information systems including third-party components, assess risk before acquiring software, monitor that software after deployment, and attest under penalty of perjury that the program is running.
Post-MGM statements from Commissioner Bedoya and the Bureau of Consumer Protection's 2024 blog posts on "vendor management" emphasize that misrepresentations about security — including those made by software vendors to their enterprise buyers — are actionable when they induce reasonable reliance. In practice, that means a vendor's security marketing becomes evidence. A buyer's reliance on unverified claims becomes negligence. The FTC's September 2024 closed-case summary of GoDaddy, for example, cited insufficient SBOM-adjacent controls as a pattern of deception.
Expect three operational obligations to solidify in 2026: documented software bills of materials, evidence of provenance for critical components, and a verifiable third-party monitoring program. Companies that cannot produce these artifacts during an investigation will face not just Section 5 liability but also civil penalties where consent orders exist.
How does the MGM incident translate into software vendor risk?
The MGM intrusion is usually framed as an identity attack: the Scattered Spider cluster (UNC3944) social-engineered an MGM IT help desk to reset credentials, pivoted through Okta, and deployed BlackCat/ALPHV ransomware against ESXi hosts. The DOJ's November 2024 indictment of five alleged Scattered Spider members (Case No. 2:24-cr-00485, C.D. Cal.) provides the underlying factual record. But the attack also turned on software: a poorly segmented privileged access workflow, a casino-floor management platform without MFA enforcement on administrative APIs, and hotel-key software whose recovery depended on out-of-band credential escrow that the attackers had already accessed.
Every one of those systems is third-party software. Every one of those systems shipped with defaults that the vendor, not MGM, chose. This is what makes the FTC's emerging theory so consequential: if a vendor ships software that defaults insecurely, and the vendor's marketing implies the product is "enterprise-grade" or "zero-trust-ready," the FTC can treat those claims as deceptive when a breach ensues. CISA's joint advisory AA23-320A on Scattered Spider lists the techniques; the FTC now has a template for mapping those techniques to vendor claims.
For security engineers this means design reviews have a new audience. A vendor's threat model must now account for regulatory readers who will ask: does the product require MFA on admin APIs, does it produce tamper-evident logs, does it ship with a documented SBOM, and can the vendor prove that a given customer received the exact build described in the release notes?
What is changing for SBOM attestation under federal contracts?
Executive Order 14028 and OMB Memorandum M-22-18 established the baseline: federal agencies cannot acquire software unless the producer attests to NIST SSDF (SP 800-218) practices. The CISA Secure Software Self-Attestation form went into full effect for critical software in June 2023 and for all covered software by September 2023. In 2024 CISA published an updated SBOM Minimum Elements document, and the FTC's January 2025 comment to NIST explicitly endorsed SBOM attestation as a baseline consumer-protection expectation, not just a federal acquisition one.
The practical implication: the gap between "federal contractor" and "commercial vendor" is narrowing. Enterprise buyers now borrow the attestation form and require their vendors to sign an equivalent. FTC orders against Drizly and Chegg already reference vendor-monitoring obligations that look like acquisition-side SSDF mappings. A 2026 vendor that cannot produce an SPDX or CycloneDX SBOM on demand is a vendor that cannot sell into regulated buyers.
Where does third-party risk management intersect FTC enforcement?
FTC consent decrees repeatedly cite failure to evaluate third-party service providers. The 2023 Drizly order (FTC Docket No. C-4780) required the respondent to assess all service providers annually and obtain written assurances that they maintained comparable safeguards. The 2024 BetterHelp order (FTC File No. 2023169) reiterated that buyers are liable for subprocessor behavior they could have discovered through reasonable diligence.
For security teams, the binding question is: what does "reasonable diligence" look like in 2026? The answer that defense counsel and regulators are converging on includes documented SBOM review, independent verification of critical CVE remediation timelines, continuous monitoring rather than point-in-time questionnaires, and a tiered risk model that distinguishes between vendors whose compromise would be material and those whose would not. Spreadsheet-based TPRM programs will not survive discovery.
How should engineering teams prepare for SBOM and provenance audits?
Three artifacts are now table stakes. First, machine-readable SBOMs generated from the actual build pipeline, not hand-curated manifests. Second, build provenance in SLSA v1.0 format or equivalent, demonstrating that the artifact shipped was the artifact built. Third, a vulnerability disclosure and remediation record that ties CVE identifiers to the specific component version in the SBOM and to the release in which the fix shipped.
Engineering teams should wire these artifacts into CI/CD rather than treating them as release-time deliverables. GitHub's artifact attestations, Sigstore's cosign, and in-toto layouts have matured enough that reproducible SBOM emission is a solved problem for most language ecosystems. Where it is not solved — embedded firmware, proprietary runtimes, legacy Windows drivers — regulators will expect to see a documented compensating control, not silence.
What does "material" mean when FTC meets SEC disclosure rules?
The FTC's enforcement theory complements, rather than competes with, the SEC's Cybersecurity Disclosure Rule finalized in July 2023 (17 CFR 229.106). The SEC requires public companies to disclose "material" cybersecurity incidents within four business days on Form 8-K. The FTC's consumer-protection theory asks whether the company's prior statements about its security posture induced the harm.
A software vendor that experiences a breach now faces both: a Form 8-K under SEC rules, and a potential Section 5 action if the vendor's pre-breach marketing overstated its controls. The DOJ's November 2024 indictment in the Scattered Spider case, alongside the SEC's October 2023 complaint against SolarWinds' CISO (SEC v. SolarWinds Corp. and Timothy G. Brown, S.D.N.Y.), gives regulators a clear precedent for pursuing vendors whose attestations do not match operational reality. The SolarWinds case was partially dismissed in July 2024 but the core theory — that public security claims are actionable — survived.
How Safeguard.sh Helps
Safeguard.sh closes the evidentiary gap that FTC investigators now routinely probe. The Eagle detection engine ingests vendor SBOMs, build provenance attestations, and binary analysis results in a single lineage graph, so a security team can answer "which of our vendors ship the vulnerable component?" in minutes rather than weeks. Eagle correlates CISA KEV entries and vendor advisories against your installed base and flags divergence between what a vendor attests and what their shipped artifacts actually contain.
The zero-day pipeline continuously monitors upstream research feeds, exploit-broker chatter, and PoC repositories; when a vendor's component is implicated, Safeguard.sh opens a ticket with the affected customer relationships pre-populated. SBOM lineage tracks component provenance across mergers, rebrands, and vendor-of-vendor relationships — the exact opacity pattern the FTC has flagged in its post-MGM guidance.
For TPRM, Safeguard.sh replaces annual questionnaires with continuous attestation checks against CISA Self-Attestation criteria and NIST SP 800-218 practices. Lino compliance mapping translates FTC consent decree language, FTC Safeguards Rule requirements, and SEC 8-K triggers into engineering controls and evidence collection obligations. When a control fails, Griffin AI remediation proposes the specific pull request, policy change, or vendor notification that closes the gap, with an audit trail that meets the documentation expectations in recent FTC orders.