Beyond the Perimeter: Building Resilience Against Cloud and SaaS Supply-Chain Attacks

A critical zero-day vulnerability in Oracle PeopleSoft exposed the Council of Europe and scores of other organizations to data theft and extortion in May and early June 2026.

The ShinyHunters hacking group exploited the flaw across about 100 organizations and 300 instances worldwide, according to reports cited by The Register. 

The attackers targeted the management and configuration layers of enterprise resource-planning systems, stealing sensitive records. 

Among these were employees’ and students’ personal data, payroll, tax and financial information, health records and immigration and passport documents.  

AgentCypher.ai estimates extortion demands of $400,000 to $2.3 million per victim – often in Bitcoin although the total remains undisclosed. The Council of Europe refused to negotiate or pay. 

Why are traditional perimeter-based security models no longer sufficient? 

The incident showed why the traditional security perimeter is no longer a reliable boundary. 

Users, applications and data now span cloud platforms, SaaS services, remote devices and third-party environments, so security can no longer depend on whether an asset sits inside or outside a corporate network.

Identity, device trust, least-privilege access and continuous verification matter more. 

The essential mindset is to assume compromise is possible and build around prevention, detection, containment and recovery. 

Mark Child, CEO of Quantum Evolve, says perimeter security assumed organisations could defend a clear boundary with firewalls, VPNs and network segmentation. 

That model is increasingly unsustainable as applications, workloads and users spread across cloud services, APIs, mobile environments and third-party ecosystems. 

AI accelerates the shift by helping attackers automate reconnaissance, create convincing social engineering campaigns and identify weaknesses at scale.

Quantum computing presents a longer-term risk to currently trusted cryptography, so organisations should be planning for cryptographic resilience now. 

Zero Trust is therefore critical. It treats the perimeter as porous and emphasises identity, continuous verification, least privilege, data protection and recovery. 

The goal is not only to prevent compromise, but also to detect, contain and survive control failures. 

SaaS and cloud supply chains expand organisational exposure  

Every cloud or SaaS service adds a dependency, and suppliers often depend on others. An organisation can have strong internal controls yet still be exposed by a compromise several layers down the chain. 

Supply-chain risk is inherited risk, so organisations must understand not only their suppliers, but also the critical services those suppliers use. 

Child notes that cloud and SaaS platforms improve agility and reduce infrastructure-management burdens, while also creating concentration risk. 

Organisations increasingly rely on a small group of cloud, identity and managed-service providers with privileged access to sensitive data and core processes. 

AI models, APIs, agents and data-processing services add further dependencies and questions about where data is processed, which models can access it and what happens if a provider is compromised. 

Delayed patching can turn these weaknesses into mass-exploitation events. 

Delayed patching increases the impact of mass exploitation 

The gap between vulnerability disclosure and active exploitation is now extremely small. Automated scanning means attackers do not need to target a particular organisation; exposed, vulnerable systems can be found quickly. 

A released patch does not remove risk until it is deployed or the vulnerability is otherwise mitigated. Internet-facing systems, identity infrastructure and vulnerabilities known to be exploited should take priority. 

Child warns that public vulnerabilities can rapidly be industrialised through automated scanning, exploit frameworks and AI-assisted tools.

Without effective asset discovery, prioritisation and risk-based patching, a theoretical weakness can become an active compromise within days—or hours. 

Operational consequences of cloud service compromise  

Cloud compromise can become a business-wide incident, affecting availability, integrity, data access, identity services and critical processes at the same time. 

If a critical service fails, organisations may simultaneously lose authentication, communications, customer systems and development environments.

Restoring availability is not enough if identities, configurations or data cannot be trusted. 

Recovery means restoring trusted business operations, including AI models, agents, APIs, data pipelines and the identities through which they operate. 

The role of encrypted, geographically distributed backups 

Encrypted, geographically distributed backups remain among the strongest resilience controls.

They should be isolated from production where possible so one cloud failure, cyberattack or physical incident cannot destroy both live and recovery environments. 

Immutable or offline copies should protect the most critical systems. An attacker who compromises production must not automatically gain the ability to erase recovery capability. 

Define recovery time objectives (RTOs) 

Recovery-time objectives should start with the business. The key question is how long a service can be unavailable before the impact becomes unacceptable.

IT and security teams can then design systems and recovery processes to meet that requirement. 

Not every service needs five-minute recovery. Priorities should reflect business criticality, regulation and operational impact; RTOs are business decisions supported by technology, not targets imposed on the business. 

Regularly test replication and recovery processes 

Backups and recovery plans must be tested regularly. Replication can stop, credentials expire, dependencies change and documentation becomes outdated. 

Testing should prove that systems can be restored and the business can operate afterwards. A backup is different from a recovery capability. 

New Perimeter: Identity security and cloud resilience  

Identity is the new perimeter. Attackers may not need to breach a network if they obtain a privileged account, session token or API credential.

Multi-factor authentication, privileged-access management, least privilege and strong monitoring are essential. 

Resilience also requires a plan for identity failure: if the identity provider is unavailable or compromised, how will administrators regain control? That question belongs in every serious disaster-recovery plan. 

Prepare for simultaneous third-party failures  

Organisations must understand concentration risk. Several apparently independent suppliers may rely on the same hyperscaler, identity provider, telecoms carrier or platform. 

Dependency mapping is therefore critical. For essential services, organisations should consider independent backups, alternative communications, secondary suppliers and documented manual processes, focusing on dependencies whose simultaneous failure would cause the greatest harm. 

Applying practical lessons  

The central lesson is that cybersecurity and business continuity can no longer operate separately. Security teams must accept that preventive controls can fail, while continuity teams must recognise that cyber recovery differs from a normal outage because systems, credentials and data may all be untrusted. 

Priorities are clear: map critical dependencies, protect identities, patch high-risk vulnerabilities rapidly, maintain isolated backups and test recovery regularly. 

Resilience must also extend to suppliers, from procurement and contracting through monitoring and exit planning.

The goal is not to make failure impossible, but to ensure failure does not become catastrophe.  

Please by-line to Mihai Popa, the Chief Information Officer of Bridgeworks Ltd. He specialises in cybersecurity, data protection, and safeguarding enterprise networks.