What Intruder's 2026 Cloud Security Index Says to Fix First: S3 HTTPS, Azure Storage and GCP OS Login

The data, and how far to trust it

Intruder’s 2026 Cloud Security Index, published on 12 August 2026, is based on anonymised data from 3,000 Intruder customers. It groups cloud issues into six categories and compares AWS, Azure and Google Cloud. We read it through a republished press release on TechIntelPro and could not find a link to the original report, so the figures below are as reported there. They come from Intruder’s own customer base, which skews toward organisations that already run external scanning, so treat them as a pattern rather than a market-wide measure.

Reported findings:

• AWS leads in prevalence across five of six categories. 76% of accounts have publicly exposed services. The most common single issue is S3 buckets that do not enforce HTTPS, at 87%. Permissive ingress to sensitive ports affects 84%, and IAM policies allowing privilege escalation affect 83%.
• Azure: the top three misconfigurations all involve storage accounts, affecting 61% to 67% of accounts. 64% have publicly exposed services, and 55% contain Entra users without MFA.
• Google Cloud has the lowest misconfiguration rates in four categories. 8% of accounts have publicly exposed services. IAM issues dominate its top four, and three of four accounts lack OS Login controls.
• Across all three, weak IAM controls affect 87% to 97% of accounts. IAM is the only category that worsens with organisation size: 87% for SMEs, 95% for midmarket and 98% for large enterprises.
• Remediation time: smaller organisations take 8 to 16 days, midmarket organisations (1,000 to 5,000 employees) peak at about 35 days, and 10,000+ employee organisations take about 10.

Below are fixes for the headline findings. Test each in a non-production account first.

AWS: enforce TLS on S3

A bucket policy that denies any request not using TLS closes the most common finding. It uses the aws:SecureTransport condition key.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::EXAMPLE-BUCKET",
        "arn:aws:s3:::EXAMPLE-BUCKET/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

Apply it:

aws s3api put-bucket-policy --bucket EXAMPLE-BUCKET --policy file://deny-insecure.json

Note that put-bucket-policy replaces any existing policy. Merge the statement into the current document (aws s3api get-bucket-policy --bucket EXAMPLE-BUCKET) instead of overwriting. To find buckets without the statement across an account:

for b in $(aws s3api list-buckets --query 'Buckets[].Name' --output text); do
  aws s3api get-bucket-policy --bucket "$b" --query Policy --output text 2>/dev/null \
    | grep -q 'aws:SecureTransport' || echo "NO TLS-ONLY POLICY: $b"
done

Also turn on S3 Block Public Access at the account level:

aws s3control put-public-access-block --account-id 123456789012 \
  --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

AWS: exposed ports and privilege escalation

For the 84% ingress finding, list security groups open to the world on sensitive ports:

aws ec2 describe-security-groups \
  --filters Name=ip-permission.cidr,Values=0.0.0.0/0 \
  --query 'SecurityGroups[].{ID:GroupId,Name:GroupName,Ports:IpPermissions[].FromPort}'

Review every result, then replace world-open rules for SSH (22), RDP (3389) and database ports with specific source ranges or a session-based access tool.

For IAM privilege escalation, no single command fixes it. Policies that grant actions such as iam:PassRole, iam:CreatePolicyVersion or iam:AttachUserPolicy without tight resource scoping are the usual culprits. Use IAM Access Analyzer, review any role that can modify IAM, and add permission boundaries for roles that developers can create. Our earlier KMS key policy article covers one related path.

Azure: storage accounts and MFA

Storage accounts dominate Azure’s top findings. The commands below are the common baseline:

az storage account update -n ACCOUNT -g RG \
  --https-only true \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false

List accounts that still permit public blob access:

az storage account list --query "[?allowBlobPublicAccess==\`true\`].{name:name,rg:resourceGroup}" -o table

Consider also restricting network access with --default-action Deny and explicit virtual network or IP rules, after confirming dependent workloads.

For the 55% of accounts with Entra users lacking MFA, enforce it through Conditional Access, requiring multifactor authentication for all users, with a break-glass exclusion that is tightly monitored. Start in report-only mode to see the impact. This is configured in the Entra admin centre rather than through a short CLI command.

Google Cloud: OS Login

Three out of four Google Cloud accounts lack OS Login controls. OS Login ties SSH access to IAM identities instead of project-wide SSH keys in metadata. Enable it project-wide:

gcloud compute project-info add-metadata --metadata enable-oslogin=TRUE

Add enable-oslogin-2fa=TRUE if you want to require two-factor authentication for logins. Existing instances may carry their own metadata overriding the project setting, so check:

gcloud compute instances list --format="table(name,zone,metadata.items.filter(key:enable-oslogin).flatten())"

Grant roles/compute.osLogin or roles/compute.osAdminLogin to the people who need them, and remove old SSH keys from project metadata once OS Login is working.

IAM across all three clouds

The report’s most striking claim is that IAM weakness grows with organisation size, reaching 98% in large enterprises. We would not read causation into that. Our interpretation is that larger organisations have more roles, more teams and more inherited permissions, which makes drift harder to see. Practical steps that scale:

1. Inventory identities with administrative or IAM-modification rights, and cut the list.
2. Replace long-lived access keys with short-lived federated credentials.
3. Run a scheduled permission-review job and track the time to close findings, not only their number.
4. Set a service-level target. The remediation figures above, with a midmarket peak of roughly 35 days, suggest the bottleneck is process rather than tooling.

Where to start

If you have one afternoon: enforce TLS and Block Public Access on S3, require HTTPS and disable public blob access on Azure storage, turn on OS Login on GCP, and report on world-open sensitive ports in every account. Then spend the following weeks on IAM, which is the finding that appears in every cloud and takes longest to fix.

Sources

• TechIntelPro (republished press release), “Intruder 2026 Cloud Security Index finds distinct security risks across major cloud providers”: https://techintelpro.com/Cybersecurity/Cloud-Security/intruder-2026-cloud-security-index-finds-distinct-security-risks-across-major-cloud-providers

The commands are standard AWS, Azure and Google Cloud CLI usage and were written from documentation knowledge. They were not executed against live accounts for this article.