Updated on: March 28, 2026
As organizations accelerate their digital transformation initiatives, the cloud has become the backbone of modern business – powering everything from SaaS platforms and APIs to global infrastructure and AI-driven applications. Yet despite years of high-profile breaches and growing investment in security tooling, cloud environments remain persistently misunderstood.
One of the most dangerous assumptions is that migrating to the cloud means transferring security responsibility along with infrastructure. As experts repeatedly emphasize, organizations outsource hardware, not accountability. The shared responsibility model adopted by major providers like Amazon Web Services has created powerful, scalable ecosystems, but it has also introduced gray zones where identity management, configurations, monitoring, and incident readiness can quietly fall through the cracks. When no one clearly owns a control, attackers inevitably will.
At the same time, cloud-native complexity has expanded the attack surface. Rapid deployments, over-permissive IAM configurations, SaaS sprawl, third-party integrations, and fragmented visibility have made risk harder to measure and manage. Meanwhile, adversaries are evolving just as quickly, increasingly leveraging automated AI-driven reconnaissance and credential-based attacks that exploit misconfigurations rather than sophisticated zero-day vulnerabilities.
In this Expert Quotes edition, SafetyDetectives brings together leading cybersecurity executives and practitioners to break down the most misunderstood cloud risks, the operational realities behind the shared responsibility model, the misconfigurations attackers exploit most often, and why automation is both strengthening and weakening cloud security at the same time.
If there is one consistent theme throughout their insights, it’s this: cloud security does not fail because the cloud is inherently insecure – it fails when ownership is unclear, visibility erodes, and disciplined fundamentals are replaced by assumptions.
What cloud security risk grows the fastest as organizations mature digitally?
As organizations mature, many will be required to review their permissions structure. Operational oversight will likely not have been given when initially setting up servers and often a single set of permissions or ssh keys will be able to access many different places. This helps developers work quickly when scaffolding a product, remaining focused and unhindered by “access requests”. However, this is not a long term approach due to the necessity to secure sensitive data and services.
To fix this, maturing teams need to move toward a Principle of Least Privilege (PoLP). This usually starts with a deep dive into who actually has access to what, followed by rotating those old legacy keys that have been floating around for years. Instead of relying on static, “forever” keys, the goal is to shift toward Role-Based Access Control (RBAC) or identity-based tokens that expire quickly. It’s less about adding red tape and more about ensuring that a single compromised credential doesn’t give someone the “keys to the kingdom.” In a modern infrastructure, moving away from these shared, permanent permissions is a necessary step to keep things secure and stable.
Chris Taylor, Founder of Prosopo
What cloud security controls are commonly implemented but rarely configured correctly? Also, how does identity and access management become more critical, and more fragile, in cloud environments?
Nearly every major cloud provider ships with security controls that are technically “on” but rarely tuned properly. Object storage is the most notorious example — buckets get provisioned quickly and left world-readable or unencrypted. Network security groups are almost always created, but rules inside them frequently contain overly permissive ingress policies left over from development. Logging is perhaps the most deceptive: CloudTrail and similar services get enabled, but without routing logs to an immutable destination or wiring alerts to an actual response workflow, you have a system that logs everything and detects nothing.
Regarding your second question – in a traditional data centre, a compromised credential meant access to one machine. In the cloud, a single stolen token — a developer key, a service account, an instance role — can span storage, compute, and databases across an entire tenancy. That expanded blast radius makes IAM the central security primitive. The fragility comes from complexity: machines now outnumber people in most cloud environments, and service identities accumulate privileges over time rather than shrink. Static keys get embedded in pipelines and forgotten. Cross-account trust chains mean one misconfigured role policy can become a pivot point that reaches everything else.
Jiri Berger, CEO of PhoneCopy
What lessons can be learned from recent high-profile cloud security incidents?
The main one is – never trust a single source for backups.
Even when our customers use their lifetime accounts, we still want them to have a backup drive – just in case. Glitches, browser issues, etc. You should, on a regular basis, go into your cloud accounts (Google, Apple, etc.) and pull out those special memories or important uploads, and secure them into an onsite backup drive.
The business model for clouds is convenience, which is great, but remember – the clock is ticking. At some point of inactivity, your data will be deleted. With terabytes of information stored on free cloud services, what do you think the AI managing data storage will do? DELETE—beep.
If you’re a business reliant upon cloud data security, it would be prudent to have redundant company security and an onsite backup that is not connected 24/7. I think we are going to have AI hackers against AI safeguards, and you better hope your AI sheriff is faster.
Cloud security, in a nutshell, is out of our hands. We need to secure what we can to the best of our ability, and report and log all incidents immediately.
James Gebhardt, CEO of MyArkit
What is the most misunderstood cloud security risk organizations face during digital transformation initiatives? Also, how does the shared responsibility model create security gaps when it’s not fully understood?
The most commonly misunderstood aspect of cloud security during digital transformation initiatives is the belief that transferring systems, applications and processes to the cloud also transfers security responsibility to the provider.
In reality, organizations outsource infrastructure, not accountability, and they remain fully responsible for their data, assets, configurations, access controls and overall security posture throughout the transformation journey.
Although cloud providers secure the underlying infrastructure, organizations must understand shared-responsibility models, verify contracts, ensure secure configurations and enable the early discovery and remediation of vulnerabilities, often in coordination with the provider.
This misconception creates dangerous blind spots, which are amplified by the rapid adoption of cloud services, third-party integrations and supply-chain dependencies, that can expand the attack surface.
The risk is further compounded when transformation programs are accompanied by organizational changes that reassign or eliminate roles previously responsible for those assets, causing a loss of critical internal know-how. The result is reduced visibility and control precisely when complexity, dependency and exposure are at their highest.
Cloud security does not fail because the cloud is insecure; rather, it fails when risk is assumed to be externalized while responsibility and expertise invisibly erode inside the organization.
And regarding the shared responsibility model and security gaps – a lack of understanding of the shared responsibility model can create security gaps because critical controls fall into areas that no one actively owns. Organizations mistakenly assume that the cloud provider is responsible for more than it actually is, while the provider operates only within its contractual scope. The result is a gray zone where configurations, identity management, access privileges, monitoring, vulnerability discovery, and incident readiness are either partially or not implemented at all.
From a business and strategic perspective, cloud resources are adopted to maximize efficiency, increase revenue, and reduce costs. However, even after compliance requirements are formally met, deeper issues often emerge. As systems, assets, and dependencies become distributed across cloud services, SaaS platforms, APIs, and third-party providers, visibility into residual cyber risk becomes fragmented and obscured by several layers of abstraction. This makes risk increasingly difficult to measure, manage, mitigate, and transfer.
This is precisely why we created HackRisk.io. By analyzing and classifying tens of thousands of publicly disclosed cyberattacks that resulted in losses, we track the severity and impact of incidents, not just their frequency and technical details.
This unique approach closes a critical information gap by providing real-world examples of the consequences of cyberattacks on organizations in similar sectors, geographies, and conditions. It enables decision-makers to better understand their potential residual risk by learning from similar organizations’ losses in similar scenarios and to base security and risk management choices on real-world data, not assumptions.
Sofia Scozzari, CEO & Founder of Hackmanac
How can shadow IT introduce cloud security blind spots, and how should organizations address it?
Shadow IT is basically what happens when smart people get tired of waiting and swipe a credit card. It introduces cloud security blind spots because suddenly data is living in tools IT doesn’t know exist, accounts aren’t tied to SSO, MFA isn’t enforced, and when someone leaves the organization, their access might leave with them… or might not. From a security perspective, that’s like trying to secure a building when people keep adding side doors you didn’t know about. It’s usually not malicious – it’s a speed and convenience problem. The fix isn’t to play “IT police,” it’s to make it easier to do the right thing than the rogue thing. Fast intake reviews, clear AI and SaaS guidelines, SSO requirements, and actually partnering with departments go a long way. If IT is responsive and solutions-oriented, people stop sneaking around – because they don’t need to.
Danon Vaughn, Founder of Ransom Shield
How do compliance requirements differ from real-world cloud security, and where do teams get confused?
One of the slides I always presented to boards and executive leadership meetings had a very simple truth: “Compliance ≠ Security”. Bridging the gap between compliance requirements and real-world security is a bit like the difference between passing a driving test and actually navigating a storm. One proves you know the rules, while the other proves you can actually survive the road.
Often, teams fall into what’s known as “security theater,” where the focus shifts toward doing just enough to keep an auditor happy rather than actually hardening the environment. It doesn’t help that many auditing firms are facing a bit of a talent shortage; it’s hard to find auditors with deep, hands-on cloud experience, which can sometimes lead to a “checkbox” culture where the nuances of a complex stack get missed. A great example of this can be found in backup, recovery and business continuity: do you have backups? Sure! However – what assets are being backed-up, what is the actual business impact if in case of data loss, when was the most recent recovery test and was it successful – not as common questions. Same goes for vulnerability assessment, patching, monitoring, etc. An additional aspect is related to the fact that technology today moves at lightning speed while standards tend to take their time catching up, leaving a gap between what’s required and what’s actually effective. It feels like we might be spending a bit too much energy on the paperwork. True security is less about a once-a-year scramble before the audit and more about making sure controls actually work through regular, ongoing testing. The Agentic era introduces new opportunities to maintain compliance and security together, with less conflict.
Ron Peled, COO and Co-founder of Sola Security
What role does automation play in both improving and weakening cloud security?
Cloud users need to carefully understand the shared security model that cloud service providers operate under, based on my experiences operating the Business Cyber Guardian Product Trust Registry (SAG-CTR) on AWS. Cyber criminals know that many cloud users may not understand their responsibilities under the shared security model and could easily miss an important step needed to ensure optimal security protections are properly configured and operating as expected. The situation is exacerbated now that cyber criminals are using automated AI tools for recon and autonomous attacks based on known vulnerabilities that may be exposed on cloud service instances.
Dick Brooks of Reliable Energy Analytics
Which cloud misconfiguration do you see exploited most often, and why does it keep happening? Additionally, how has rapid cloud adoption outpaced security team readiness in most organizations?
The most exploited cloud misconfiguration today is over-permissive identity and access management (IAM). In many organizations, users, service accounts, and applications are granted far broader access than they need. This often happens during rapid deployments, troubleshooting, or integration with third-party services, where permissions are expanded to “make things work” and are rarely revisited afterward. Once excessive access becomes part of the environment, it tends to persist unnoticed.
Attackers increasingly target these weaknesses because they provide a low-effort, high-impact path into cloud environments. Rather than exploiting sophisticated technical vulnerabilities, threat actors rely on stolen credentials, phishing, or exposed tokens to authenticate legitimately. When identity controls are overly permissive, attackers can move laterally, access sensitive data, and establish persistence without triggering obvious security alarms. From the cloud provider’s perspective, these actions look like normal, authorized behavior.
This issue continues to occur because cloud identity models are complex and difficult to design correctly without specialized expertise. Responsibility for IAM is often fragmented between development, infrastructure, and security teams, leading to unclear ownership and inconsistent governance. In addition, the pressure to deliver quickly in cloud environments frequently outweighs security considerations, reinforcing a culture where access is widened by default. As a result, many cloud breaches are not caused by technical flaws, but by environments functioning exactly as they were configured – just not as securely as intended.
Rapid cloud adoption has fundamentally reshaped how organizations build and operate their IT environments, but security teams have struggled to
keep pace with the speed and scale of this transformation. Cloud platforms enable continuous deployment, infrastructure automation, and near- instant scalability, which significantly reduces the time between idea and production. While this agility is a major business advantage, it also introduces highly dynamic environments that are difficult to secure using traditional security models.
Many security teams were designed to protect relatively static infrastructures, relying on perimeter-based controls, scheduled assessments, and manual review processes. In cloud environments, assets are ephemeral, configurations change constantly, and responsibility for security is shared between the provider and the customer.
This shift requires new skills in cloud architecture, identity management, and automation – areas where many organizations face clear capability gaps. As a result, security is often introduced too late in cloud projects, after systems are already live and critical to the business. Security teams are then forced into a reactive role, attempting to regain visibility and control over environments they did not help design. In some cases, organizations deploy multiple cloud security tools, but without the processes or expertise needed to use them effectively.
The gap is not simply technological; it is organizational. Cloud adoption has outpaced not just security tooling, but the operating models, skills, and governance structures needed to manage risk in modern cloud environments.
Martin Petrov, Cybersecurity Service Lead at Amatas
Which cloud security assumptions made during early migration phases tend to fail at scale?
The assumption that breaks most consistently is that visibility will somehow take care of itself.
Organisations migrate to the cloud believing their existing monitoring tools will extend naturally into AWS, Azure, or multi-cloud environments. They assume CloudTrail logs and native dashboards will be enough. At twenty accounts and a handful of regions, maybe. But at scale (50+ accounts, hybrid workloads, SaaS sprawl, contractor access through third-party IdPs) those assumptions collapse.
The second failure is treating cloud security as a day-one design exercise rather than an ongoing operational discipline. Teams architect beautifully secure landing zones, pass their initial audits, then hand it over to DevOps. Six months later, the environment has drifted. Shadow deployments exist. Permissions have crept. Configurations no longer match the blueprint. Without continuous monitoring, detection, and response capability, that initial security posture becomes fiction.
The organisations that succeed at scale treat cloud security as an always-on operation. They invest in unified visibility across their entire environment: not just cloud, but the network layer, identity fabric, and SaaS perimeter. They build teams that can respond to alerts, not just generate them. Security in the cloud isn’t a migration deliverable. It’s a capability you operate, day two and beyond.
Stuart Long, Chief Technology Officer at Orro
What cloud security mistake(s) do organizations keep repeating despite years of high-profile breaches?
High-profile breaches keep making headlines, yet many organizations still fall into the same cloud security traps. One of the biggest misconceptions is believing that “being in the cloud” (or buying managed services “from the cloud”) automatically means you’re secure.
Security is proven through controls and for many organizations, those controls are measured through compliance. A SOC 2 Type II data centre or service provider can give you a strong foundation, but it doesn’t make your organization compliant by default. Compliance depends on what your team does every day: how accounts are managed, how changes are approved, how incidents are handled, and whether those processes are followed and audited.
Here are the repeat mistakes we see most often:
1) Assuming the provider secures everything
Cloud providers and managed service partners can secure the underlying infrastructure, but most incidents happen in the customer-controlled layer: identities, configurations, endpoints, and data access. If responsibilities aren’t clearly defined, gaps like over-permissioned accounts and unreviewed admin access can linger for years.
2) Weak identity practices
Stolen credentials are still a top entry point. Common issues include inconsistent MFA, shared admin accounts, and privileges that grow over time but never get reviewed. In the cloud, identity isn’t just important … it is the perimeter.
3) “Set-and-forget” configurations
Cloud and DMZ environments change constantly. New apps, new users, and new integrations can quietly introduce risk. Continuous monitoring and regular configuration reviews are essential to catch exposure before it becomes an incident.
4) Buying “24/7” but responding 8×5
Organizations invest in 24/7/365 security services, but their internal escalation and decision-making still run on business hours. A 2:00 a.m. alert that waits until morning can turn a small event into a major outage. Detection and response must be aligned with clear on-call coverage and tested playbooks.
5) Backups and recovery that aren’t tested
Backups aren’t a strategy unless recovery is proven. Define RTO/RPO per system and validate them with regular restore tests and tabletop exercises.
“Cloud security isn’t about more tools. Rather, it’s about disciplined fundamentals, continuously.”
Rick Beyers is the Founder and President of Aegisys Cloud Solutions, a trusted Canadian SOC 2 Type II certified Managed Service Provider (MSP) specializing in managed IT services, fast, reliable, and secure VPS hosting, and robust cybersecurity for organizations across Ontario and beyond.
To learn more, visit https://aegisys.com or the Aegisys Trust Centre at https://trust.aegisys.com .
What are the most common risks associated with third-party integrations in the cloud?
The most common and dangerous risks with cloud integrations is how private application keys can be exposed, or permissions can be easily exploited by malicious actors if not protected adequately.
These concerns and many others can arise from a lack of developer experience or a lack of precision when directing AIs to manage a specific integration.
Another concern is how user data privacy and ownership is managed by each third party application, with each company having varying scopes of information usage and sharing, where even if your core, proprietary platform is explicitly designed with encryption, data can still be leaked and exploited with a third party application openly uses shared data for purposes outside of the service being provided to your end users (examples include them claiming ownership over your confidential and proprietary IP or using it for AI training), which can result in a lack of trust from your audience and potential regulatory fines.
For this reason, it is important to have a trusted executive or engineer audit and enhance your systems in parallel to a strong AI strategy to stay ahead and build a robust security infrastructure in place to ensure that your organization’s growth continues unaffected.
Diego Torres, CEO of Jada AI
