The European Union’s Cyber Resilience Act (CRA) has captured global attention because of the new approach it brings to regulating software and connected products. The CRA doesn’t stop at compliance checkboxes. It introduces four principles that reshape how vendors must think about security: Products should launch without known vulnerabilities, security must be built in from the design phase, vulnerabilities must be managed across the entire lifecycle, and vendors must be prepared to deliver rapid updates when issues arise. The common thread is clear. Resilience needs to be embedded from the start rather than bolted on after incidents. 

Though born in Europe, the CRA’s influence will eventually spread far beyond EU borders. Global vendors cannot realistically maintain different development and security standards across markets. Like General Data Protection Regulation (GDPR) before it, the CRA will shape how products are built, shipped, and maintained worldwide. U.S. companies should pay close attention, not only because they may fall under its scope, but also because domestic regulators are moving in the same direction. The SEC’s new disclosure rules, the FTC’s scrutiny of negligent practices, and the growing number of state-level data protection laws all point to a world where resilience isn’t a “nice to have.” 

SaaS as the CRA’s Proving Ground 

Software-as-a-service (SaaS) is one of the most overlooked proving grounds for CRA principles. SaaS applications are now the backbone of modern organizations, from sales and finance to HR and engineering. They are also a prime target for attackers, precisely because they sit at the intersection of sensitive data, federated identity and complex integrations. 

The recent Salesloft breach shows why CRA-style requirements matter here. In March, attackers compromised a GitHub workflow, stole OAuth tokens, and leveraged them to access Salesforce environments connected to Salesloft. This was not a traditional exploit of unpatched software, but it did involve weaknesses in the vendor’s security practices. Stronger controls, rapid patching, immediate reporting and more secure development pipelines – the exact requirements envisioned by the CRA – would have reduced the likelihood and impact of such an incident. 

In this sense, CRA provides a useful framework for SaaS vendors. “No known vulnerabilities” at launch, a continuous vulnerability management process and lifecycle security obligations – together set a baseline for responsible SaaS development. 

Why Compliance Alone Won’t Stop the Next Breach 

But this is only half the story. Even the most diligent vendor can ship a service that is technically free of known vulnerabilities, and customers may still find themselves compromised. Some of the most dangerous attacks don’t exploit software flaws. They exploit people. 

The wave of vishing campaigns targeting Salesforce customers shows this clearly. Groups like ShinyHunters convinced employees to hand over valid Salesforce credentials through phone and voice phishing schemes. With real logins in hand, attackers moved laterally, accessed sensitive records and exfiltrated data. No unpatched vulnerability was needed. 

Attackers don’t break in. They log in. When valid credentials or tokens are abused, the principle of lifecycle security and even strong vulnerability handling are not enough. Prevention-focused approaches are bypassed entirely, underscoring the need for resilient defenses. 

Shared Responsibility is the Only Way Forward 

This brings us to the heart of the matter: SaaS security is inherently a shared responsibility. The CRA rightfully raises the bar for vendors, demanding secure-by-design practices, vulnerability handling and timely updates. But customers cannot outsource all accountability. 

Vendors must: 

• Harden their code, pipelines and integrations. 

• Provide rapid updates and transparency when vulnerabilities are found.  

• Build in protections against unauthorized access. 

• Report exploited vulnerabilities or incidents quickly to the authorities. 

Customers must: 

• Monitor how identities are used across SaaS applications. 

• Detect and respond to suspicious logins, anomalous activity, or unauthorized integrations. 

• Educate employees to resist social engineering and phishing campaigns. 

• Integrate SaaS events into detection and response workflows. 

Resilience in SaaS comes not from compliance checkboxes, but from this balance. Vendors secure the foundation, and customers build vigilance on top of it. Both sides must act. 

A Preview of What’s Coming 

The CRA points the way for global regulation: Resilience, accountability and lifecycle security. U.S. regulators may not choose to adopt the exact same framework, but the principles are already visible in SEC disclosure mandates and FTC enforcement. For companies operating in the U.S., the safest path is to prepare as if CRA-style rules are inevitable. 

Organizations must do both: Hold vendors accountable and build detection and response capabilities for when attackers inevitably log in. Organizations that treat resilience as a partnership – vendors building secure platforms, customers monitoring identity and activity – will be far better positioned than those who view compliance as a finish line. 

Resilience Demands Shared Responsibility 

The Cyber Resilience Act is a step forward for software security, and SaaS vendors should embrace its principles. But it would be a mistake to assume that compliance alone will deliver resilience. As the Salesloft breach shows, vendor practices matter. As the Salesforce vishing campaigns show, so does customer vigilance. 

Attackers in the SaaS era exploit both technology and people. They don’t break in. They log in. The only way forward is shared responsibility. Vendors and customers must accept that resilience is a joint mission. Those who act on that understanding will not only stay ahead of regulators but will also be ready for the next wave of attacks.