Most small businesses don't run their own web applications. Their accounting, CRM, project management, file storage, HR, payments, support desk, and often even their core operating platform are SaaS — delivered by someone else, hosted on someone else's infrastructure, and reachable by anyone on the public internet with a browser.

That was already the quiet reality of modern business IT. What has changed in 2026 is that the public internet itself has become a much more dangerous neighborhood to keep your data in.

Dark Reading put it plainly in a recent piece: "Every Old Vulnerability Is Now an AI Vulnerability." The claim isn't that AI is inventing exotic new bug classes — it's that AI is weaponizing the old ones faster than defenders can patch them. For SMBs, that translates to a concrete question most owners haven't had to ask before: how good is the security posture of every SaaS vendor I depend on?

What Actually Changed

The shift is best understood through two threads: AI is finding more vulnerabilities, and attackers are exploiting them faster.

  • Anthropic's Claude Mythos Preview — a frontier model currently restricted to a small set of partners under its Project Glasswing program — reportedly identified thousands of previously unknown high-severity vulnerabilities across every major operating system and web browser, including a 27-year-old denial-of-service flaw in OpenBSD's TCP SACK implementation that had been dormant since 1998. Industry reporting notes that more than 99% of those findings were still unpatched at the time of disclosure.
  • Sysdig's Threat Research team observed in-the-wild exploitation of Marimo (CVE-2026-39987) 9 hours and 41 minutes after public disclosure, with no public proof-of-concept code released. Credential theft completed in under three minutes of initial access.
  • A parallel critical flaw in Langflow (CVE-2026-33017) came under active exploitation within roughly 20 hours of disclosure, triggering a CISA advisory and addition to the Known Exploited Vulnerabilities catalog.
  • VulnCheck's State of Exploitation 2026 found that 28.96% of known-exploited vulnerabilities in 2025 were weaponized on or before the day their CVE was published — up from 23.6% the year prior.

Put those numbers together and the old unwritten assumption — "we have a few days between a fix being announced and attackers running it against us" — no longer holds. We covered the AI side of this story in more depth in our piece on AI-powered vulnerability discovery and what Opus 4.6's zero-day findings mean for business.

Why Your SaaS Providers Are Now the Front Line

Every SaaS product you use is, by definition, a publicly reachable web application. Its login page is on the internet. Its API is on the internet. Its admin panel, often, is on the internet. That's the entire point of SaaS — accessibility is the product.

That accessibility is also the attack surface. Whether the vendor is a hyperscaler with thousands of engineers or a three-person startup with a clever idea, the same CVE clock is now ticking against them. The difference is that a hyperscaler has a dedicated product security team, a bug bounty program, a patching pipeline, and an incident response org. The small startup often has none of those — and in an era where attackers weaponize flaws in hours, "we'll get to it" is no longer an acceptable answer.

This matters to you because a breach at any SaaS vendor you rely on is effectively a breach of your business data. The boundary between "their security" and "your security" doesn't really exist anymore.

How to Evaluate a SaaS Provider's Security (A Practical Checklist)

You don't need a CISO to ask good questions. These are the ones that separate serious vendors from the rest.

1. Authentication: Does the Vendor Offer Proper MFA?

This is the single best canary for a SaaS vendor's overall security maturity. You're looking for:

  • MFA available on every account tier (not gated behind an enterprise plan).
  • Support for authenticator apps (TOTP) and, ideally, hardware keys or passkeys. SMS-only MFA is better than nothing but is no longer a robust control — attackers routinely defeat it through SIM swaps and phishing.
  • MFA enforcement controls for admins (the ability to require it across the workspace, not just make it optional).

A SaaS vendor that in 2026 still does not offer proper MFA is telling you something important about what's happening — or not happening — under the hood. If basic authentication hygiene isn't a priority, vulnerability management almost certainly isn't either. Our guide to phishing-resistant authentication, hardware keys, and passkeys covers what "proper MFA" actually looks like today.

2. Identity: SSO and Least-Privilege Roles

For any vendor that will touch meaningful business data, look for:

  • SAML or OIDC single sign-on so you can centralize identity, disable leavers instantly, and enforce your own MFA policy.
  • Role-based access control with real separation between admin, user, and billing roles.
  • Audit logs you can export, covering logins, permission changes, and data access.

SSO being locked behind a top-tier enterprise plan (sometimes called the "SSO tax") is a mild yellow flag — it's common, but worth factoring into your risk calculus for smaller vendors.

3. Security Certifications and Third-Party Attestations

Not a silver bullet, but a reasonable floor:

  • SOC 2 Type II for US-centric vendors.
  • ISO/IEC 27001 (and increasingly 27701 for privacy) for international vendors.
  • HIPAA, PCI DSS, or sector-specific standards if you handle that kind of data.

Ask for the report, not just the logo. A vendor unwilling to share a SOC 2 under NDA is a vendor whose posture you cannot verify.

4. Vulnerability and Patch Management

This is where the AI era bites hardest. Questions worth asking:

  • Do you have a public security.txt or vulnerability disclosure policy?
  • What is your internal SLA for patching critical vulnerabilities? If the answer is fuzzy, assume it's slow.
  • Do you run a bug bounty or external pentesting program?
  • How are you thinking about AI-accelerated vulnerability disclosure? A vendor that has an answer has at least thought about it.

5. Breach and Incident History

A prior incident isn't automatically disqualifying. Silence or evasion usually is.

  • Has the vendor disclosed a breach? How quickly? What did they change afterward?
  • Do they have a documented incident response process and a named point of contact for customers?

Our note on incident response planning before something happens is a useful mirror — the same things you want from a vendor are the things you should have in-house.

6. Data Handling, Residency, and Export

  • Where is your data stored and processed? (Region matters for privacy law and jurisdiction.)
  • Can you export a complete copy of your data on demand, in a standard format?
  • What is the vendor's policy on sub-processors — the third parties they in turn rely on? Their weakest sub-processor is effectively part of your attack surface too.

Broader context on this lives in our piece on third-party vendor risk from an SMB perspective.

7. The "Small Vendor, Big Exposure" Question

Small SaaS vendors are often where the most useful product innovation happens. They're also often the most exposed. If a tool is indispensable but the vendor is a five-person team, it's worth asking explicitly: what happens to our data if this company disappears, gets acquired, or has a serious breach next quarter? Mitigations — regular exports, contractual data return, limits on what data you put in — are a lot cheaper to put in place before something goes wrong than after.

Own Your Backups

SaaS vendors back up their infrastructure so they can keep running. That is not the same as backing up your data so you can keep running when something happens to them.

Ransomware events, accidental mass deletions by an admin, malicious insiders, prolonged outages, and company failures all produce the same outcome for you: data you relied on is no longer available when you need it. In 2026, with AI-accelerated exploitation pressuring every publicly exposed SaaS, that probability is not going down.

At minimum, for any SaaS holding data your business cannot afford to lose:

  • Pull an independent backup on a regular schedule — daily for high-change data, weekly for the rest.
  • Store it somewhere other than the SaaS itself (ideally with a 3-2-1 pattern: three copies, two different media, one off-site).
  • Test a restore at least annually. An untested backup is a hypothesis, not a safety net.

Our guides on ransom-proofing your backups and the backup and recovery assumptions that fail walk through how this goes wrong in practice.

For the Web Apps You Do Own: Private-by-Default

Some of your systems aren't SaaS — they're things you host yourself: internal dashboards, admin panels, file servers, remote-access gateways, development environments, line-of-business apps. The AI-era math says these should not be on the public internet unless they absolutely have to be.

The good news is that the tooling to make internal apps private has matured. Zero Trust Network Access (ZTNA), usually delivered as part of a broader SASE (Secure Access Service Edge) platform, is now a realistic option for organizations that a few years ago would have defaulted to a traditional VPN. A zero-trust SASE solution:

  • Hides your apps from the public internet entirely — scanners and attackers can't probe what they can't see.
  • Authenticates every request based on user identity, device posture, and context, not just a one-time login.
  • Grants per-application access instead of dropping users onto a flat network segment the way a legacy VPN does.
  • Works consistently from anywhere — office, home, coffee shop, mobile — without the performance and management overhead of classic VPN concentrators.

This is a meaningful shift from the traditional VPN model, which has itself become a common target. According to Zscaler's ThreatLabz 2025 VPN Risk Report, published VPN CVEs grew by 82.5% over the sample period, and 56% of organizations surveyed reported a VPN-related breach in the prior year. Our primer on why zero-trust matters for SMBs covers the broader concept, and our overview of reducing your attack surface walks through the practical first steps.

If you can reasonably keep an internal app off the public internet, you should. It is the single highest-leverage control available, because it removes you from the CVE race entirely for that asset.

Modernizing Your Patch SLA

For whatever remains exposed — whether a SaaS vendor you can pressure, or a web app you own — the old "72 hours to patch critical vulnerabilities" target deserves a refresh:

  • Internet-exposed, critical severity: hours, not days. Use WAF rules, temporary access blocks, or geofencing as stopgaps if a vendor patch isn't immediately available.
  • Internet-exposed, high severity: 24–72 hours, weighted by exploitability and whether a public PoC exists.
  • Internal, segmented systems: traditional 7–30 day cycles are still reasonable.
  • SaaS you depend on: if you can't patch it, you can at least monitor their status page, subscribe to their security advisories, and have an answer ready for "what do we do if they're breached."

The Bottom Line

The headline "every old vulnerability is now an AI vulnerability" is a useful simplification of something real: AI is making the long-accumulated backlog of software flaws exploitable at machine speed. For small businesses, the most important implication isn't about one tool or one CVE — it's that the security posture of every SaaS vendor in your stack has quietly become a load-bearing part of your own security posture.

Vet them accordingly. Keep your own backups. And for the systems you still run yourself, take them off the public internet when you can — modern zero-trust SASE makes that more practical than it has ever been.

If you'd like a second set of eyes on your SaaS stack, your backups, and what you currently have exposed, our free cybersecurity assessment is designed exactly for this. It's built for small and medium-sized businesses and focuses on the kind of exposure AI-assisted attackers are most likely to find first.

This article is intended for informational purposes only and does not constitute professional security, legal, or compliance advice. Organizations should consult with qualified professionals to assess their specific circumstances and develop appropriate protective measures.