The Next Breach May Start with a Login Not Malware

A SaaS incident is a business incident

A compromised identity, an overprivileged application, or an unavailable SaaS platform can disrupt operations without encrypting a laptop. The important planning question is which services the business depends on, how access is controlled, and what happens when the service or its data can no longer be trusted. The specific developing news example in the draft is omitted here; the security planning guidance does not depend on attributing that incident.

Supporting reference: Identity, the first pillar of a Zero Trust security architecture ↗

Ransomware used to follow a pretty predictable script. Someone clicked something they shouldn't have, machines got encrypted, a ransom note appeared, and everything ground to a halt. That playbook still exists. But it's not the only one you need to worry about anymore.

The good news is there's a lot you can do right now, without standing up a new security initiative.

Start with a clear-eyed inventory of the SaaS platforms that actually run your business, not just what IT manages, but what people actually use. For each one: who owns it, what sensitive data does it hold, who has admin access, and what third-party integrations or delegated permissions are hanging off it? Most organizations find more exposure here than they expected.

Then tighten identity around those platforms. Phishing-resistant MFA for privileged accounts, Conditional Access policy review, stale admin cleanup, standing privilege reduction. Pay attention to service accounts, break-glass accounts, and external users, they have a way of quietly becoming the easiest path in. If someone can reach a critical SaaS app from an unmanaged device or an unknown location without additional friction, that's worth fixing now.

Make sure you can actually see what's happening. Suspicious sign-ins, impossible travel, unusual admin activity, mass downloads, risky OAuth grants, mailbox anomalies, changes to security settings, if that telemetry isn't flowing into your SOC or SIEM, you may not know something is wrong until users are already locked out.

And run the business continuity scenario before you have to live it. What happens if a core platform is down for 24 hours? What if data from that platform gets posted publicly? Who calls the vendor? Who talks to users? What manual fallback exists? What evidence can your team actually produce? These are uncomfortable questions, and a lot easier to answer now than during the incident.

By the time people can't get into the ticket queue, the CRM, or the finance system, the debate over whether it technically counts as ransomware won't matter much because your business will already be feeling it.