Your Cloud Hyperscaler Is Not Secure by Default

When an organisation moves workloads to AWS, Azure, or Google Cloud, it inherits a powerful, globally distributed infrastructure. What it does not inherit is a secure configuration. The hyperscaler provides the platform. The organisation is responsible for what runs on it, how it is configured, who can access it, and whether any of it is visible to the internet.

This distinction matters more than most organisations realise. Gartner has estimated that 99% of cloud security failures through 2025 would be the customer's fault, primarily through misconfiguration. The Australian Cyber Security Centre (ACSC) published executive guidance in October 2025 reinforcing the same point: moving to the cloud does not transfer your governance obligations. It changes the shape of your responsibilities, but it does not reduce them.

This article explains what the shared responsibility model actually means in practice, where cloud security gaps most commonly appear, and what a cloud security posture assessment should cover to give your organisation genuine visibility into its cloud risk.

Why Your Cloud Hyperscaler Is Not Secure by Default

Cloud hyperscalers are designed for flexibility, not security. Their default configurations prioritise ease of use and rapid deployment. That means storage buckets can be publicly accessible by default. IAM roles can be created with broad permissions. Logging is often disabled until someone turns it on. Multi-factor authentication is not enforced unless you configure it.

In 2021, researchers at UpGuard discovered that over 1,000 Microsoft Power Apps portals had been misconfigured to allow public access, exposing 38 million records including COVID-19 contact tracing data, employee information, and vaccination status. The root cause was a default setting: table permissions in Power Apps portals were set to allow public access unless explicitly changed. Organisations using the platform had not changed them.

In 2023, Toyota disclosed that a misconfigured cloud storage bucket had exposed the vehicle data of 2.15 million customers for a decade. The bucket had been set to public access. No one had noticed. These are not edge cases. They are the predictable consequence of deploying cloud services without a structured approach to configuration, access control, and ongoing posture review.

The hyperscalers have made improvements. AWS introduced Security Hub. Azure has Defender for Cloud. Google Cloud has Security Command Center. These tools help, but they require configuration, integration, and active management. They do not make your environment secure by default. They give you the instruments to measure it, if you choose to use them.

What the Shared Responsibility Model Really Means

Every major cloud provider publishes a shared responsibility model. The core principle is consistent: the cloud provider is responsible for the security of the cloud (the physical infrastructure, the hypervisor, the global network), and the customer is responsible for security in the cloud (the data, the applications, the access controls, the configuration).

Where the model gets more nuanced is across service types. With Infrastructure as a Service (IaaS), the customer manages the operating system, middleware, applications, and data. With Platform as a Service (PaaS), the provider takes on more of the stack, but the customer still owns data, access management, and application-level configuration. With Software as a Service (SaaS), the provider manages almost everything, but the customer remains responsible for who has access, what data is stored, and how the service is configured.

Google Cloud has gone further than its peers in framing this as a shared fate model, acknowledging that the provider has a stake in customer security outcomes and offering more prescriptive guidance and tooling. But even under a shared fate framing, the customer's configuration decisions, identity controls, and data governance remain their own responsibility.

The ACSC's October 2025 guidance is direct on this point: organisations cannot outsource their governance obligations to a cloud provider. Legislative and regulatory requirements, including those related to data sovereignty, privacy, and critical infrastructure, remain the customer's responsibility regardless of where the workload runs.

What the Cloud Provider Secures

To be clear about what you are getting: the hyperscalers invest heavily in the security of their underlying infrastructure. Physical data centre security, hardware integrity, network isolation between tenants, the hypervisor layer, and the global backbone are all managed by the provider. They maintain certifications across ISO 27001, SOC 2, PCI DSS, and many others. Their infrastructure is, by most measures, more physically secure than anything most organisations could build themselves.

The managed services layer is also largely the provider's responsibility. If you use a managed database service like AWS RDS, Azure SQL, or Google Cloud SQL, the provider patches the database engine. If you use a managed Kubernetes service like EKS, AKS, or GKE, the provider manages the control plane. The further up the stack you go toward SaaS, the more the provider manages.

What the provider does not do is tell you that your S3 bucket is publicly accessible, that your service account has owner-level permissions across your entire project, that your virtual machine has a public IP address and no firewall rule restricting inbound traffic, or that your audit logging has been disabled. Those are your decisions to make, and your responsibility to monitor.

What Your Organisation Still Owns

Regardless of which cloud provider you use or which service model you operate under, your organisation retains responsibility for a consistent set of security domains. Understanding these is the starting point for any cloud security programme.

Identity and access management is the most consequential. Cloud environments are controlled through APIs, and APIs are controlled through identity. Every human user, every service account, every workload identity, and every third-party integration has permissions. If those permissions are too broad, or if credentials are exposed, an attacker can move through your environment without ever touching a vulnerability. IAM misconfiguration is consistently one of the top causes of cloud security incidents.

Data protection is your responsibility. Encryption at rest and in transit, key management, access controls on storage, and data classification are all customer-managed. The provider offers the tools. You decide whether to use them and how to configure them.

Network configuration, including security groups, firewall rules, virtual private cloud design, and public exposure of services, is customer-managed. So is application security: the code you deploy, the container images you run, the APIs you expose, and the secrets you store in environment variables or configuration files.

Logging and monitoring is a particularly common gap. AWS CloudTrail, Azure Monitor, and Google Cloud Audit Logs provide comprehensive audit trails, but they are not enabled everywhere by default, and they are not connected to a SIEM or alerting system unless you configure that integration. Many organisations discover after an incident that the logs they needed were never being collected.

Where Cloud Security Gaps Commonly Appear

Cloud environments are dynamic. Resources are created and destroyed continuously. Developers provision infrastructure through code. Teams move fast. Security controls that were in place last quarter may not apply to the new workloads deployed this sprint. This dynamism is one of the cloud's greatest strengths and one of its most significant security challenges.

The most common gaps Fortura observes in cloud environments cluster around a few consistent themes. Overprivileged identities: service accounts and IAM roles with far more permissions than their function requires, often created quickly and never reviewed. Publicly accessible resources: storage buckets, databases, and management interfaces exposed to the internet without business justification. Missing or incomplete logging: audit trails that don't cover all services, all regions, or all account activity. Secrets in the wrong places: API keys, database credentials, and access tokens stored in code repositories, environment variables, or container images. Unpatched workloads: virtual machines and containers running outdated software because the patching process that worked on-premises was never adapted for cloud.

Lateral movement paths are a particular concern. In a cloud environment, an attacker who compromises a single workload identity can often use that identity to access other services, assume other roles, or read data across the environment. The blast radius of a single compromised credential is frequently much larger than the organisation realises, because IAM permissions were never modelled from an attacker's perspective.

The Problems Organisations Face With Cloud Hyperscaler Security

The challenges organisations face with cloud security are not primarily technical. They are organisational, operational, and structural. Understanding them is the first step toward addressing them.

What a Cloud Security Posture Assessment Should Cover

A cloud security posture assessment is a structured review of your cloud environment's configuration, access controls, and security controls against known best practices, threat patterns, and your organisation's specific risk context. It is not a vulnerability scan. It is not a compliance checklist. It is an analysis of whether your cloud environment is configured in a way that reduces the likelihood and impact of a security incident.

A well-structured assessment covers resource discovery (what exists in your environment, across all accounts, regions, and services), configuration analysis (whether resources are configured securely, including storage access, network exposure, encryption, and logging), identity and access review (who and what has access to what, whether permissions are appropriate, and whether privileged access is adequately controlled), threat correlation (whether identified gaps align with known attack techniques and threat actor behaviour relevant to your sector), and business context prioritisation (which findings represent the greatest risk given the criticality of the affected systems and data).

The output of a useful assessment is not a list of findings sorted by severity. It is a prioritised remediation roadmap that tells your team what to fix first, why it matters, and what the business impact of not fixing it is. That distinction, between a findings report and an actionable risk picture, is what separates a useful assessment from a compliance exercise.

Why Identity, Logging, and Exposure Matter More Than Tool Coverage

Many organisations approach cloud security by asking which tools they have deployed. Do we have a CSPM? Do we have a CNAPP? Do we have cloud-native security tooling enabled? These are reasonable questions, but they miss the point. Tools generate findings. What matters is whether the findings are being acted on, and whether the three most consequential risk domains are being managed effectively.

Identity is the control plane of the cloud. Every action in a cloud environment is an API call, and every API call is authenticated by an identity. If your identities are overprivileged, poorly governed, or compromised, an attacker can operate within your environment using legitimate credentials. They don't need to exploit a vulnerability. They just need to find a service account key in a public GitHub repository, or phish a developer with broad IAM permissions, or exploit a misconfigured workload identity that has access to your production database.

Logging is your ability to know what happened. Without comprehensive audit logging across management plane activity, data access, and authentication events, you cannot detect an intrusion, investigate an incident, or demonstrate compliance. AWS CloudTrail, Azure Monitor, and Google Cloud Audit Logs are powerful, but they need to be configured, centralised, and connected to detection tooling. The default state is often insufficient.

Exposure is what an attacker can reach from the internet. Public storage buckets, internet-facing management interfaces, APIs without authentication, and virtual machines with unrestricted inbound access all represent exposure. Reducing exposure is one of the highest-leverage things an organisation can do to reduce its cloud attack surface, because it limits the entry points available to an attacker before they have even authenticated.

How to Prioritise Cloud Findings Using Business Context

A mature CSPM tool deployed across a large cloud environment will generate hundreds or thousands of findings. Research suggests that many organisations remediate fewer than 20% of cloud security findings, not because they don't care, but because the volume is unmanageable without a principled approach to prioritisation.

Business context is what makes prioritisation meaningful. A misconfigured storage bucket containing marketing assets is a different risk than a misconfigured storage bucket containing patient health records or financial transaction data. An overprivileged service account on a development workload is a different risk than an overprivileged service account with access to your production payment processing environment.

Effective prioritisation combines three inputs: the technical severity of the finding, the business criticality of the affected system or data, and the threat relevance of the gap (whether it aligns with techniques used by threat actors targeting your sector). A finding that scores high on all three dimensions warrants immediate attention. A finding that scores low on all three can be tracked and addressed in a normal remediation cycle.

This is the difference between a cloud security posture assessment and a compliance review. A compliance review tells you whether you meet a standard. A posture assessment, done well, tells you which gaps represent the greatest risk to your organisation given your specific environment, your data, your threat landscape, and your business context.

Practical Recommendations for Improving Cloud Security Posture

Improving cloud security posture does not require replacing your cloud provider or rebuilding your architecture. It requires applying consistent controls across the domains that matter most, and maintaining visibility as your environment changes.

Fortura Perspective

At Fortura, we work with organisations that have moved significant workloads to the cloud and are now grappling with the security implications of that decision. The pattern we see most often is not a lack of tooling. It is a lack of visibility, a lack of prioritisation, and a gap between what the security team knows and what the business understands about its cloud risk.

Our Cloud Security Posture Assessment gives organisations a clear, prioritised picture of their cloud security risk. We combine automated discovery and analysis with manual review to identify misconfigurations, access gaps, and exposure across your cloud environment. We apply threat intelligence and business context to prioritise findings by actual risk, not by technical severity alone. The output is a remediation roadmap your team can act on, not a spreadsheet of findings sorted by CVSS score.

For organisations that need a broader view of their external exposure, our Threat and Attack Surface Assessment maps what is discoverable from the internet and assesses how real-world threat actors could exploit that exposure in your specific business context. For organisations that want to understand whether their cloud security controls are actually working, our Threat-Informed Validation service tests detection and response capability against realistic attack scenarios relevant to your environment.

Our Vulnerability Assessment service complements cloud posture work by identifying exploitable weaknesses across systems and environments, applying the same threat and business context to ensure remediation effort follows genuine exposure. And where cloud security decisions need to be grounded in a broader risk framework, our NIST CSF Alignment and Assessment and Zero Trust Architecture and Design services help organisations build security programmes that are coherent, defensible, and aligned to how their business actually operates.

If you are not confident that your cloud environment is configured securely, or if you have cloud security tooling but are not sure whether it is giving you an accurate picture of your risk, a structured posture assessment is a practical starting point. Reach out to the Fortura team to start the conversation.

Conclusion

Cloud hyperscalers are not secure by default. They provide powerful, flexible infrastructure with strong physical and network security at the infrastructure layer. What they do not provide is a secure configuration for your workloads, your data, your identities, or your access controls. That responsibility sits with your organisation, and it does not diminish as you move further up the service stack.

The shared responsibility model is not a risk transfer mechanism. It is a division of labour. Understanding where your responsibilities begin, and maintaining ongoing visibility into whether you are meeting them, is the foundation of effective cloud security.

The practical next step for most organisations is an honest assessment of their current cloud posture: what exists in their environment, how it is configured, who has access to it, and whether any of it is visible to the internet in ways that create unnecessary risk. That assessment, done well and with business context applied to the findings, is the starting point for a cloud security programme that actually reduces risk rather than just generating reports.