Cloud Security Baseline 2026: Critical Controls for AWS, Azure and Multi-Cloud Environments

Cloud intrusions in the first half of 2025 already exceeded all of 2024 by 136 per cent, according to CrowdStrike's 2025 Threat Hunting Report. The culprit is not novel zero-day exploits — it is the same preventable problem that has topped breach reports for years: misconfiguration. Public storage buckets left open after a legacy migration, long-lived access keys rotating nowhere, logging disabled to cut costs, MFA exemptions granted for convenience and never revoked. For Australian organisations operating under the Privacy Act 1988 and the Australian Cyber Security Centre's Essential Eight framework, the consequences now extend beyond breach costs to regulatory exposure, mandatory notifications, and reputational damage before the Board has even been briefed. This article defines a practical 2026 cloud security baseline — the minimum set of controls every cloud-connected Australian organisation should have operating by end of financial year, regardless of whether your primary platform is AWS, Azure, or both.

Why Baseline Controls Keep Failing

The shared-responsibility model is widely understood in theory and routinely misapplied in practice. Cloud providers secure the underlying infrastructure — physical hardware, hypervisors, global network fabric. Everything above that line — identity configuration, data classification, network segmentation, encryption choices, and logging — belongs to the customer. According to research aggregated by SentinelOne, over 80 per cent of cloud security incidents originate from human error, inconsistent policies, or poor change control within the customer's own environment. Unit 42 found that 99 per cent of cloud identities carry more permissions than they ever use. These are not exotic attack vectors; they are administrative failures that well-implemented baseline controls eliminate.

The 2026 challenge is compounded by scale and speed. Infrastructure-as-code pipelines spin up dozens of new resources a day. Multi-cloud strategies mean security teams must maintain consistent controls across AWS and Azure simultaneously. AI-assisted development accelerates delivery but can introduce insecure-by-default configurations if guardrails are not built into the pipeline. The baseline that follows addresses each of these pressure points.

Identity and Access — The Perimeter That Actually Matters

Over 70 per cent of cloud breaches now involve compromised or over-provisioned identities. Identity is the cloud perimeter, and the 2026 baseline treats it accordingly.

Least Privilege and Permission Right-Sizing

Every human and machine identity should carry only the permissions required for its defined function — nothing more. This means auditing existing IAM roles and policies against actual CloudTrail or Entra ID sign-in logs, identifying unused permissions, and removing them. On AWS, IAM Access Analyzer automates this detection. On Azure, Microsoft Entra ID Governance provides access reviews that can be scheduled quarterly and enforced automatically. Wildcard permissions (Action: "*" or Contributor assigned at subscription scope) should be replaced with scoped, resource-specific policies.

No Long-Lived Static Credentials

Long-lived access keys are among the most exploited cloud credentials. The 2026 baseline prohibits static IAM access keys for service workloads entirely. On AWS, this means replacing key-based authentication with IAM Roles for EC2, Lambda, and ECS workloads, and using OIDC federation for CI/CD pipelines. On Azure, managed identities replace service principal credentials in nearly every scenario. Where programmatic access is unavoidable, keys must be stored in AWS Secrets Manager or Azure Key Vault with automatic rotation enabled and a maximum 90-day lifetime enforced via policy.

Multi-Factor Authentication Without Exceptions

MFA enforcement must be absolute for all human access to cloud consoles and APIs. On AWS, Service Control Policies (SCPs) can deny all API calls unless the requesting session was authenticated with MFA. On Azure, Conditional Access policies enforce MFA for every sign-in, with named location and device compliance conditions layered on top. Break-glass emergency accounts are the only permissible exception — and these must be monitored with alerts on every use.

Just-in-Time Privileged Access

Persistent privileged access is a standing invitation for lateral movement. Microsoft Entra Privileged Identity Management (PIM) provides time-bound, approval-gated elevation to privileged Azure roles with full audit trails. On AWS, a similar pattern is achieved by combining AWS IAM Identity Center with permission sets that activate only on explicit request. No administrator should hold always-on access to production environments.

Encryption — At Rest and In Transit, Without Compromise

Encryption is a non-negotiable baseline control, not a premium feature. The 2026 baseline mandates:

Encryption at rest for all storage services using customer-managed keys (CMKs) where data is classified as sensitive or regulated. AWS KMS and Azure Key Vault both support CMKs with enforced annual or more frequent key rotation. Enforce this via AWS Config rules or Azure Policy.
Encryption in transit enforced by policy across all load balancers, API gateways, and service-to-service communications. On AWS, enforce TLS 1.2 or higher on ALBs and disable unencrypted S3 bucket access with a bucket policy denying aws:SecureTransport: false. On Azure, the Secure transfer required property must be enabled on all storage accounts, and Application Gateway policies should reject deprecated cipher suites.
Key management governance — no use of default service-managed keys for regulated data categories. Rotation schedules must be documented and verified via automated compliance checks monthly.

Logging and Native Threat Detection — See Everything

You cannot defend what you cannot see. The 2026 baseline treats comprehensive logging as mandatory infrastructure, not optional overhead.

AWS: CloudTrail, VPC Flow Logs, and GuardDuty

AWS CloudTrail must be enabled in every region across every account in the organisation, with logs delivered to a centralised, write-protected S3 bucket in a dedicated security account that member accounts cannot modify. VPC Flow Logs should be enabled for every VPC. AWS GuardDuty — the native ML-based threat detection service — must be active in all regions and all accounts, with S3 Protection and EKS Protection add-ons enabled. GuardDuty findings feed into AWS Security Hub for centralised visibility, where CIS AWS Foundations Benchmark v5.0.0 provides the compliance posture baseline. Critical findings trigger automated response via EventBridge and Lambda remediation playbooks.

Azure: Diagnostic Logs, Microsoft Defender for Cloud, and Sentinel

On Azure, diagnostic settings must stream activity logs, resource logs, and Entra ID sign-in logs to a Log Analytics Workspace in a dedicated security subscription. Microsoft Defender for Cloud should be enabled across all subscriptions with the Microsoft Cloud Security Benchmark (MCSB) applied by default — this provides over 420 built-in policy assessments and a Secure Score that makes posture degradation visible before it becomes a breach. The MCSB's 12 control domains cover identity, networking, data protection, logging, endpoint, and DevOps. For organisations requiring SIEM capability, Microsoft Sentinel connects natively and provides UEBA, threat intelligence integration, and incident automation.

Network Controls — Least-Access Segmentation

Default-allow network postures are a consistent breach enabler. The baseline mandates:

No security group or Network Security Group (NSG) rule permitting unrestricted inbound access (0.0.0.0/0) on management ports (SSH/22, RDP/3389). All management access routes through AWS Systems Manager Session Manager or Azure Bastion, eliminating open inbound ports entirely.
VPC and VNet designs follow hub-and-spoke or landing zone patterns with explicit peering controls. Production, non-production, and security workloads are isolated in separate accounts or subscriptions.
Web-facing workloads sit behind AWS WAF or Azure Web Application Firewall with managed rule sets enabled and DDoS Protection enabled at the network layer.
Private endpoints replace public endpoints for all PaaS services (S3, Azure Storage, RDS, Azure SQL) wherever feasible, reducing the public attack surface to zero for data-tier resources.

Data Classification and Sovereignty

Australian organisations handling personal information under the Privacy Act 1988 and the Australian Privacy Principles (APPs) have data sovereignty obligations that cloud architecture must reflect. The 2026 baseline requires:

A documented data classification taxonomy — at minimum: Public, Internal, Confidential, Regulated — applied at the S3 bucket or Azure Storage container level via tagging and enforced via Service Control Policies or Azure Policy deny effects.
All Regulated and Confidential data stored in Australian regions only (ap-southeast-2 on AWS; australiaeast / australiasoutheast on Azure). Guardrails must prevent workloads from accidentally replicating regulated data to non-Australian regions.
Cross-border transfer controls — where data must leave Australia, document the lawful basis under APP 8 and implement contractual safeguards or use cloud providers with IRAP PROTECTED assessments. AWS services have been assessed by the ACSC at the PROTECTED level; Azure's Australian regions hold equivalent assessments.
Microsoft Purview or AWS Macie deployed to discover and classify sensitive data at rest, with findings integrated into the security operations workflow.

Policy-as-Code and Automated Compliance

Manual compliance checks do not scale. The 2026 baseline integrates security into the infrastructure provisioning lifecycle itself.

Infrastructure-as-Code Security Gates

All cloud infrastructure is provisioned via Terraform, AWS CloudFormation, or Bicep — never via manual console clicks in production. IaC templates are scanned pre-deployment using tools such as Checkov, tfsec, or Semgrep against CIS Benchmark and MCSB rule sets. Findings above a defined severity threshold block the deployment pipeline. This shifts security left to where it is cheapest to fix.

Continuous Compliance Monitoring

AWS Config with conformance packs maps controls to CIS AWS Foundations Benchmark v5.0.0 and alerts on drift within minutes of a change. Azure Policy with built-in initiatives for the MCSB enforces configuration at deployment time and remediates non-compliant resources automatically where a remediation task is defined. Neither platform should be in a posture where a misconfiguration can persist for days undetected.

Zero Trust Applied to Cloud

Zero Trust is not a product — it is a design philosophy: assume breach, verify explicitly, use least privilege access. In a cloud context this translates to:

No implicit trust between services. East-west traffic between microservices is authenticated via service mesh mutual TLS or AWS VPC Lattice with IAM-based authorisation policies.
Workload identity, not network location. A workload's permissions derive from its identity (IAM role, managed identity) not from which VPC or subnet it sits in.
Continuous validation. Session tokens have short expiry. Conditional Access re-evaluates risk signals continuously rather than only at sign-in. Anomalous API call patterns trigger automated investigation workflows.
Verified devices. Workstations accessing cloud management consoles must satisfy device compliance policy managed via Microsoft Intune or equivalent MDM, enforced via Conditional Access or IAM Identity Center device trust conditions.

Essential Eight Alignment for Australian Organisations

The ASD Essential Eight provides the minimum baseline for Australian government entities and is increasingly the benchmark for private-sector organisations handling personal or sensitive data. Cloud implementations map directly to several Essential Eight strategies:

Patch applications / Patch operating systems — AWS Systems Manager Patch Manager and Azure Update Manager provide automated patching with compliance dashboards and Maturity Level 2 or 3 targets requiring defined patch windows.
Application control — AWS and Azure both support allowlisting approaches for Lambda functions, container images, and VM workloads via signed image registries and execution policies.
Restrict administrative privileges — directly addressed by the JIT access and MFA controls above.
Multi-factor authentication — enforced at the platform layer as described, covering all cloud console and API access.
Regular backups — AWS Backup and Azure Backup with immutable vault policies ensure backups cannot be deleted or encrypted by ransomware for a defined retention period. Testing restoration is mandatory quarterly.

AWS provides Prescriptive Guidance on reaching Essential Eight maturity that maps specific AWS services to each mitigation strategy and maturity level — a valuable starting point for organisations building their compliance evidence packs.

AWS and Azure Quick-Reference Checklists

AWS Baseline Checklist

CloudTrail enabled in all regions, delivered to immutable central S3 bucket
GuardDuty active in all regions and all accounts (including S3 and EKS Protection)
Security Hub enabled with CIS AWS Foundations Benchmark v5.0.0
No root account access keys; root MFA enforced
No long-lived IAM user access keys for service workloads
S3 Block Public Access enabled at organisation level via SCP
S3 bucket policies deny aws:SecureTransport: false
KMS CMKs with annual rotation for all regulated data stores
VPC Flow Logs enabled for all VPCs
No security group rules permitting 0.0.0.0/0 on ports 22 or 3389
AWS Config conformance packs deployed and alerting on drift
All production infrastructure deployed via IaC with pre-deployment scanning
All regulated data scoped to ap-southeast-2 via SCP deny on other regions
AWS Backup with immutable vaults for critical workloads

Azure Baseline Checklist

Defender for Cloud enabled on all subscriptions with MCSB applied
Diagnostic logs streaming to Log Analytics Workspace in security subscription
Entra ID sign-in and audit logs retained for minimum 90 days
MFA enforced via Conditional Access for all user accounts — no exceptions
Privileged Identity Management (PIM) for all Azure AD privileged roles
No Contributor or Owner assignments at subscription scope for service accounts
Managed identities replacing all service principal credentials
Secure transfer required enabled on all storage accounts
Azure Key Vault CMKs with rotation for regulated data stores
NSGs deny inbound 0.0.0.0/0 on RDP and SSH — Bastion used instead
Private endpoints for all PaaS data services
Azure Policy initiatives enforcing MCSB with deny effects for critical controls
Regulated data restricted to australiaeast / australiasoutheast via Policy
Azure Backup with immutable vault policy for critical workloads

Key Takeaways

Misconfiguration is still the leading cloud breach cause — over 80 per cent of incidents originate from customer-side configuration errors, not provider-side vulnerabilities.
Identity is the cloud perimeter. Eliminate static credentials, enforce MFA without exception, implement JIT privileged access, and right-size permissions continuously.
Native detection tools are table stakes. AWS GuardDuty and Microsoft Defender for Cloud provide ML-based threat detection that every organisation should have active in every account and region, with findings centralised for triage.
Encryption and data sovereignty are non-negotiable for Australian organisations under the Privacy Act. Restrict regulated data to Australian regions, use CMKs, and enforce transfer controls at the policy layer.
Policy-as-code eliminates drift. Manual compliance reviews cannot keep pace with modern cloud delivery. IaC scanning, AWS Config, and Azure Policy automation are the only sustainable path to continuous compliance.
Essential Eight alignment is achievable natively. AWS and Azure provide services that directly satisfy multiple Essential Eight strategies — the gap is typically in configuration and governance, not capability.
Zero Trust is a posture, not a product. Verify every identity, every request, from every network location — never assume that being inside a VPC confers trust.

Defining a cloud security baseline is not a one-time project — it is a continuous operating discipline. The organisations that fare best in 2026 are those that have codified their baseline into policy, automated its detection, and integrated its verification into every deployment pipeline. If your organisation is ready to assess your current cloud posture against this baseline, our team can help you identify gaps, prioritise remediation, and build the governance framework to keep you compliant as your cloud footprint grows. Schedule a GRC Assessment with our team today, or explore how our managed security operations service provides ongoing baseline monitoring and threat detection across your AWS and Azure environments.