Cloud Security Assessment (2026): What It Tests on AWS, Azure and GCP

Identity, not the cloud provider's infrastructure, is where cloud intrusions begin. Mandiant found that attackers exploited identity issues to gain initial access in 83% of the incidents involving major cloud and SaaS environments that its incident response and managed defense teams worked in the second half of 2025 (Google Cloud, Cloud Threat Horizons Report H1 2026). In the same report, misconfiguration fell from 29.4% to 21% of initial access into Google Cloud workloads, while exploitation of third-party software rose to 44.5%. Configuration hygiene is improving; the weaknesses that remain are trust relationships, credentials and software that no settings check describes. That is the gap a cloud security assessment has to close.

Quick answer: A cloud security assessment is an evaluation of whether the identity, configuration, network and workload controls in an AWS, Azure or Google Cloud environment are implemented correctly and would hold up against an attacker. It ranges from a configuration review against the CIS Benchmarks, to an automated CSPM or CNAPP scan, to a cloud penetration test that proves which weaknesses chain into access to production data. Run a configuration review to fix hygiene, keep posture scanning on between tests, and buy a penetration test when an auditor, an enterprise customer or a major change needs proof of what an attacker can actually reach.

This guide defines the term, compares the three depths side by side, lists what gets tested on each provider, walks through the identity attack paths that scanners rate low, and covers the steps, deliverables and what an auditor will accept. Provider policies and benchmark names were checked against the official pages on 25 October 2026, and every figure links to its source.

Key facts

• Identity is the way in: identity issues gave attackers initial access in 83% of cloud and SaaS incidents Mandiant worked in H2 2025 (Google Cloud Threat Horizons Report H1 2026).

• Misconfiguration is shrinking as a vector: 21% of initial access into Google Cloud workloads in H2 2025, down from 29.4% in H1 (same report).

• The top-ranked threat: the Cloud Security Alliance's Top Threats to Cloud Computing 2026, released 12 August 2026, ranks inadequate identity and access management as the leading threat (CSA).

• Old credentials persist: 59% of AWS IAM users have an active access key older than one year, and only 49% of EC2 instances enforce IMDSv2 (Datadog State of Cloud Security, October 2025).

• No provider permission slip: AWS, Azure and Google Cloud all let customers test resources they own without prior approval, inside published rules (AWS, Microsoft, Google Cloud).

• The configuration baselines: the CIS Amazon Web Services Foundations Benchmark (v7.1.0), CIS Microsoft Azure Foundations Benchmark (v6.0.0) and CIS Google Cloud Platform Foundation Benchmark (v5.0.0) are the latest versions CIS lists (CIS).

• Verified findings, not alerts (Stingrai data): 9 of 1,216 findings logged across 55 Stingrai penetration tests were false positives, a rate of 0.74%, because a finding only exists once a penetration tester has reproduced it (State of Penetration Testing 2026).

What is a cloud security assessment?

A cloud security assessment is an authorized evaluation of an AWS, Azure or Google Cloud environment that tests whether its identity, configuration, network, workload and data controls are implemented correctly and whether an attacker could get past them.

The wording follows the US government definition of a security assessment, the testing or evaluation of security controls "to determine the extent to which the controls are implemented correctly" (NIST CSRC glossary). In the cloud, those controls are mostly software: IAM policies, role trust relationships, resource policies, network rules, Kubernetes RBAC and the settings on managed services. All of them sit on the customer's side of the shared responsibility line. AWS describes its own job as protecting "the infrastructure that runs all of the services offered in the AWS Cloud", while the customer configures security groups, manages data and uses IAM to "apply the appropriate permissions" (AWS Shared Responsibility Model). A cloud security assessment tests that customer side.

The term covers work of very different depth, which is why two quotes for a "cloud security assessment" can differ by a factor of ten. In practice it means one of three things, or a combination:

1. A configuration review: a read-only check of accounts, subscriptions and projects against the CIS Benchmarks and the provider's security guidance.

2. A CSPM or CNAPP scan: an automated tool that continuously evaluates configuration state through the provider's APIs and flags drift.

3. A cloud penetration test: penetration testers start from an agreed position (an external view, a leaked key, a compromised workload) and try to chain identity, configuration and workload weaknesses into access to production data or the control plane.

What about a cloud security risk assessment? A cloud security risk assessment rates threats to cloud assets by likelihood and impact so that a risk owner can decide what to fix, accept or insure. It is a governance exercise, and its quality depends on the evidence fed into it. The technical assessment this guide describes is that evidence: a risk register that says "IAM privilege escalation: medium likelihood" means far more when a penetration tester has shown whether the path exists.

Cloud security assessment vs CSPM scan vs cloud penetration test

The three depths answer different questions. A configuration review asks whether settings match a baseline. A CSPM asks whether they still match today. A penetration test asks what an attacker can reach from here.

A CSPM is the right tool for drift, and every mature cloud program should run one. Its limit is structural, and the vendors say so. AWS's own posture service, now named AWS Security Hub CSPM, maps standards such as the CIS AWS Foundations Benchmark to controls and runs checks against them, and AWS states that those controls "don't guarantee compliance" but provide a way to "evaluate and monitor the state" of accounts and resources (AWS Security Hub CSPM documentation). State is the operative word. A posture tool reads configuration one control at a time. It does not assume the role it flagged, follow the trust relationship to the next account, or show that the path ends at the customer database. Our guide to CNAPP blind spots covers the four classes of finding posture tooling cannot validate.

A cloud penetration test is the deepest form of assessment. NIST describes penetration testing as security testing that mimics real attacks to find ways to circumvent the security features of a system (NIST CSRC glossary, SP 800-115). For a buyer's view of how those engagements are delivered and priced, see our cloud penetration testing services guide.

What gets tested on AWS, Azure and GCP

The categories are the same on every cloud; the services, identity models and benchmarks are not. Use this checklist to confirm a proposal covers each layer for the providers you run.

AWS security assessment

An AWS cloud security assessment usually starts from the account structure: AWS Organizations, the accounts that hold production data, and the roles that cross between them. Configuration is measured against the CIS Amazon Web Services Foundations Benchmark, which CIS lists at version 7.1.0, alongside the separate CIS benchmarks for AWS compute, database, storage and end-user compute services (CIS). Customers may test their own AWS infrastructure without prior approval for the services on AWS's permitted list, which begins with EC2 instances, WAF, NAT gateways and Elastic Load Balancers. Denial of service, request flooding, Route 53 DNS hijacking or zone walking, and S3 bucket or subdomain takeover are prohibited, and red team exercises, command and control, simulated phishing and malware testing need a Simulated Events form filed at least two weeks ahead (AWS Customer Support Policy for Penetration Testing). For a SOC 2 audit on AWS, our SOC 2 Type II cloud pentest scope guide sets out what the auditor looks for.

Azure cloud security assessment

On Azure, the subscription is rarely the real boundary; Entra ID is. App registrations, service principals and consent grants decide what a compromised identity can do, and Conditional Access decides where it can sign in from. The configuration baseline is the CIS Microsoft Azure Foundations Benchmark, listed at version 6.0.0 (CIS). Microsoft has not required pre-approval for penetration testing against Azure resources since 15 June 2017, but customers and authorized third parties must follow the Microsoft Cloud Unified Penetration Testing Rules of Engagement, which prohibit denial of service testing of any kind and the use of credentials that are not your own (Microsoft Learn). The Azure and Entra ID scoping guide lists the assets to hand to your testers.

GCP security assessment

Google Cloud's resource hierarchy (organization, folders, projects) means a role granted high up the tree reaches everything beneath it, and service accounts are both identities and resources that other principals can act as. Note the benchmark name: it is the CIS Google Cloud Platform Foundation Benchmark, singular, listed at version 5.0.0 (CIS). Google does not require customers to contact it before penetration testing their own Cloud infrastructure, provided the tests only affect their own projects and comply with the Acceptable Use Policy and Terms of Service (Google Cloud Security FAQ). Our GCP scoping guide covers the surface an AWS-shaped scope misses, and the cloud rules of engagement reference puts all three policies side by side.

Identity attack paths: the findings scanners rank low

The most serious cloud findings are often built from permissions that each look reasonable on their own. A posture tool evaluates them one at a time and rates each as low or informational; an attacker evaluates them together.

Attacker behavior points the same way. In Google's own incident data for the second half of 2025, misconfiguration, the class posture scanning is built to catch, accounted for 21% of initial access into Google Cloud workloads, behind third-party software exploitation and weak or absent credentials (Google Cloud Threat Horizons Report H1 2026).

These are the paths a cloud security assessment should test, each documented by the provider itself:

• Passing a more powerful role (AWS). iam:PassRole lets a user hand a role to a service such as Lambda or EC2. AWS warns administrators to make sure a user cannot pass a role with more permissions than the user is meant to have (AWS IAM documentation). A developer policy with an unscoped PassRole is a quiet route to administrator.

• Cross-account trust without an external ID (AWS). AWS defines the confused deputy problem as an entity without permission coercing "a more-privileged entity" to act for it, and recommends the external ID condition for third-party role trust (AWS IAM documentation).

• CI pipelines federated into production (all three). OIDC lets a CI runner assume a cloud role without stored keys. Mandiant reported that attackers now target this identity store directly, and that an overly permissive OIDC-linked role turns the pipeline into "a crown jewel access vector" (Google Cloud Threat Horizons Report H1 2026).

• Application owners acting as the application (Azure). Microsoft notes that an Entra ID application can hold more permissions than its owner, which is "an elevation of privilege" because the owner can act while impersonating the application (Microsoft Learn).

• Service account impersonation (Google Cloud). Principals with the iam.serviceAccounts.getAccessToken permission, granted by roles such as Service Account Token Creator, can impersonate a service account, which Google says lets them access "whatever the service account can access" (Google Cloud IAM documentation).

• Long-lived keys and metadata credentials. 59% of AWS IAM users have an active access key older than a year, and only 49% of EC2 instances enforce IMDSv2 (Datadog State of Cloud Security, October 2025). Each is a credential an attacker can reuse once a workload or a laptop is compromised.

Our cloud IAM penetration testing guide goes deeper on how these paths are mapped, and the GitHub Actions OIDC trust test matrix covers the CI case.

A sample finding and its remediation

The finding below is an illustrative composite of a common pattern, not a client result. It shows the format a useful cloud assessment report should follow.

Finding: any repository in the GitHub organization can obtain production deployment credentials.

• Severity: Critical in this example, because the path ends with read access to the production customer database.

• What the scanner saw: the production deploy role trusts GitHub's OIDC provider and its trust policy includes a condition on the subject claim. The posture check for "OIDC role without a subject condition" passes. AWS IAM itself blocks a subject condition that is solely a wildcard, so the policy saves without error (AWS IAM documentation).

• What testing showed: the condition matches every repository in the organization rather than the one deployment repository and branch. A workflow in a low-value test repository could therefore assume the deploy role. That role held an unscoped iam:PassRole, so it could attach an administrative role to a new function, and from there read the database credentials in the secrets store.

• Why it matters: AWS warns that if the subject condition is not limited to a specific organization or repository, workflows outside your control can assume the role, and recommends limiting it "to a specific set of repositories or branches" (AWS IAM documentation). An organization-wide wildcard is inside your organization but still far wider than intended.

• Remediation: restrict the subject claim to the deployment repository and a protected branch or environment; add GitHub environment protection rules; scope iam:PassRole to named roles with the Resource element and the iam:PassedToService condition key (AWS IAM documentation); review CloudTrail for earlier role assumptions from unexpected repositories.

• Retest: confirm that a workflow in another repository is denied, and that the deploy role can no longer pass the administrative role.

No single setting in that chain is a high-severity misconfiguration. The finding is the chain, and it only exists once someone has walked it.

Kubernetes and serverless

Managed Kubernetes adds a second identity system on top of the cloud's own. A cloud security assessment should test the cluster API endpoint's exposure, RBAC and service account tokens, admission controls, network policies between namespaces, and, most importantly, the bridge between pod identity and cloud IAM (IRSA or EKS Pod Identity on AWS, workload identity on AKS, Workload Identity Federation for GKE). Exposure is common: Datadog found the API server exposed to the internet on 39% of EKS clusters, 34% of AKS clusters and 54% of GKE clusters, and 13% of EKS clusters had a dangerous node role, one that grants full administrator access, privilege escalation, overly broad data access or lateral movement across the account's workloads (Datadog State of Cloud Security, October 2025). The configuration baselines are the CIS Kubernetes Benchmark and the CIS Amazon EKS, Azure AKS and Google GKE Benchmarks (CIS).

Serverless functions shift the question from "is the host patched" to "what can this function's role do, and who can trigger it". Testing covers function execution roles, event sources and triggers that accept untrusted input, API Gateway authorization, and secrets passed through environment variables. For cluster-heavy estates, our cloud and Kubernetes scoping and cost guide and the Kubernetes multi-tenant isolation test matrix cover the detail.

Cloud security assessment steps and timeline

A cloud security assessment that ends in usable evidence follows six steps.

1. Scope and authorize. List the accounts, subscriptions and projects in scope, the clusters and data stores that matter most, the identity providers behind them, and the starting point (external, assumed-breach foothold, read-only reviewer role, or a combination). Confirm each provider's current testing policy and record the resource owner's written authorization, the testing window and source IP ranges.

2. Inventory and baseline. Enumerate identities, roles, trust relationships, public endpoints and data stores, and measure configuration against the relevant CIS Benchmark.

3. Map exposure. Test what is reachable from the internet: management interfaces, public storage, exposed APIs and leaked credentials in public repositories and container registries.

4. Test identity attack paths. From the agreed foothold, try privilege escalation, cross-account or cross-project movement, workload credential abuse and CI federation paths toward the control plane and production data.

5. Test workloads and data. Assess Kubernetes clusters, serverless functions and managed services, and confirm whether production data is actually reachable.

6. Report and retest. Document each attack path with evidence, severity and provider-specific remediation, then retest once fixes are deployed.

At Stingrai, a read-only configuration review of one account, subscription or project typically takes 3 to 5 testing days. Attack path testing is sized by the number of accounts and projects, clusters, IAM complexity and the starting point, and the schedule is fixed in writing at scoping (Stingrai cloud penetration testing). Findings reach the client as they are confirmed, so remediation starts during the test rather than after the report.

Deliverables and how findings are prioritized

A cloud security assessment report should let three audiences act without a follow-up meeting:

• Engineering: each finding with the affected resources, step-by-step reproduction evidence and remediation mapped to the specific provider service and policy.

• Leadership: a plain-language view of what an attacker could reach, the blast radius, and the fixes to make first.

• Auditors and customers: methodology, scope, testing dates and retest status, plus an attestation letter for human-led engagements.

Prioritize by reachable impact, not by the number of failed controls. A path from a public foothold to production data outranks fifty benchmark gaps that lead nowhere, and a benchmark gap that sits on that path should be fixed with it. Ask every provider how a finding becomes a finding. In Stingrai's State of Penetration Testing 2026 data (55 tests and 1,206 verified findings across web application, internal network, external network and mobile testing; cloud is not a separate segment), only 9 of 1,216 logged findings were false positives, because each one had to be reproduced by a penetration tester and pass two stages of review (Stingrai, 2026). The same data shows why a scan alone is not enough: 37.2% of findings fell into classes a scanner could in principle flag, and almost as many, 35.2%, into classes that depend on understanding how the system is supposed to work. Treat those splits as a pattern from adjacent testing, not a cloud benchmark. For what a complete report looks like, see our penetration testing report sample.

When an auditor or enterprise customer will accept it

Auditors and enterprise security reviewers rarely ask for a "cloud security assessment" by name. They ask for evidence that controls on your side of the shared responsibility line were independently tested, and the depth decides whether you have it.

• Your provider's SOC 2 report is not your evidence. It covers the provider's controls; your configuration, identities and workloads are the complementary user entity controls you own. Our CSP compliance report vs cloud pentest evidence guide walks through what auditors accept and reject.

• SOC 2: a penetration test is not mandatory, but the AICPA criteria list penetration testing among the separate evaluations an organization can use under CC4.1, and many auditors and enterprise customers expect one for cloud-hosted systems in scope.

• PCI DSS v4.0.1: Requirement 11.4 requires internal and external penetration testing of the cardholder data environment, including segmentation checks, wherever it is hosted. A CSPM report does not meet it.

• ISO/IEC 27001:2022: cloud testing supports Annex A 8.8, management of technical vulnerabilities, and 8.9, configuration management.

• Enterprise security questionnaires: reviewers commonly ask for a third-party penetration test from the last 12 months, the scope it covered, the testing dates and proof that critical and high findings were remediated and retested.

The pattern is consistent. Configuration reviews and CSPM output count as hardening and monitoring evidence. Independent testing evidence comes from a penetration test with named testers, a dated scope and retest results. Stingrai's penetration testing supports SOC 2, ISO 27001, PCI DSS, HIPAA and CMMC programs, and every human-led cloud engagement includes an attestation letter stating scope and testing dates.

What drives the cost of a cloud security assessment

Cloud assessments are quoted to scope, not sold as a package, because the environments vary too much for a flat price to be honest. Six factors set the number of testing days: the accounts, subscriptions and projects in scope and how they trust each other; one provider or several; the number and size of Kubernetes clusters and serverless functions; IAM complexity; the starting point (external, foothold, configuration review or a combination); and whether it is a one-time assessment or a continuous program. The cloud and Kubernetes scoping and cost guide explains each driver.

If the application running in the cloud also needs testing, scope it separately: Stingrai's Hybrid Pentest covers one web application and associated APIs at US$6,800 one-time, or US$1,275 per month on a 12-month plan (Stingrai pricing), while cloud infrastructure is quoted to scope.

How Stingrai runs cloud security assessments

Stingrai is a global CREST-accredited penetration testing services company founded in Toronto, Canada in 2021, trusted by companies from startups to enterprises to meet audit requirements for SOC 2, ISO 27001, CMMC, PCI DSS and HIPAA. OSCE³, OSWE, OSEP, CREST CRT certified penetration testers, who are also world-class security researchers and bug bounty hunters. Choose from fully human-led or hybrid (AI agents plus human penetration testers) engagements across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements.

Cloud engagements at Stingrai are human-led. Two named penetration testers from a team holding OSCE³, OSWE, OSEP, CREST CRT and CISSP certifications test AWS, Azure and Entra ID, and Google Cloud from identity and the control plane down to workloads and data: cross-account role assumption, resource and bucket policies and instance metadata abuse on AWS; app registrations, service principals, consent grants and Conditional Access gaps on Azure; service account impersonation chains, IAM Conditions and GKE or Cloud Run on Google Cloud. Configuration is measured against the CIS Benchmarks for each provider, and each attack path is posted to the PTaaS portal with reproduction evidence as soon as it is confirmed, with live chat with the assigned testers and Jira and Slack integration. Reports are reviewed by a team lead and an engagement partner, retesting is included, and every human-led engagement comes with an attestation letter. Engagements run as a one-time assessment or a continuous program that retests as accounts and clusters change.

Snipe, Stingrai's autonomous AI penetration testing agent, tests web applications and their APIs. It is not used for cloud infrastructure scope.

Next step: Cloud penetration testing service | Get a quote | Book a scoping call

Frequently Asked Questions

What is a cloud security assessment?

A cloud security assessment is an authorized evaluation of an AWS, Azure or Google Cloud environment that tests whether its identity, configuration, network, workload and data controls are implemented correctly and whether an attacker could get past them. It can be a configuration review against the CIS Benchmarks, an automated CSPM or CNAPP scan, or a cloud penetration test that proves which weaknesses chain into access to production data.

What is the difference between a cloud security assessment and a cloud penetration test?

A cloud penetration test is the deepest form of cloud security assessment. A configuration review or posture scan reports which settings fail a baseline; a penetration test has penetration testers start from an agreed foothold and chain identity, configuration and workload weaknesses to show what an attacker can actually reach, with reproduction evidence and a retest.

Is a CSPM or CNAPP scan a cloud security assessment?

A CSPM or CNAPP scan is an automated, continuous form of configuration assessment, and it is the right tool for catching drift. It evaluates configuration state one control at a time, so it does not prove exploitability or confirm chained attack paths. AWS states that its own Security Hub CSPM controls do not guarantee compliance and instead evaluate and monitor the state of accounts and resources.

Do I need permission from AWS, Azure or Google Cloud for a cloud security assessment?

No prior approval is needed to test resources you own on any of the three providers, inside their published rules. AWS allows testing of its permitted services without approval but requires a Simulated Events form at least two weeks ahead for red team exercises, simulated phishing and malware testing; Microsoft dropped pre-approval for Azure on 15 June 2017 but its rules of engagement still apply; Google requires that tests only affect your own projects. Denial of service testing is prohibited on all three, and a third-party tester always needs the resource owner's written authorization.

What is a cloud security risk assessment?

A cloud security risk assessment rates threats to cloud assets by likelihood and impact so that a risk owner can decide what to fix, accept or insure. It is a governance exercise, and its quality depends on the technical evidence fed into it; a configuration review or cloud penetration test supplies that evidence.

How long does a cloud security assessment take?

At Stingrai, a read-only configuration review of one account, subscription or project typically takes 3 to 5 testing days. A cloud penetration test takes longer and is sized by the number of accounts and projects, Kubernetes clusters, IAM complexity and the starting point, with the schedule fixed in writing at scoping.

Will an auditor accept a cloud security assessment?

It depends on the depth. Configuration reviews and CSPM output count as hardening and monitoring evidence, while independent testing evidence for SOC 2, PCI DSS Requirement 11.4 and enterprise security reviews usually means a penetration test with named testers, a dated scope and retest results. Your cloud provider's own SOC 2 report covers only the provider's side of the shared responsibility line.

Related reading

• Cloud Penetration Testing Services (2026): AWS, Azure and GCP Buyer's Guide and CNAPP Blind Spots: What Cloud Posture Tools Cannot Validate

• Cloud IAM Penetration Testing and Cloud Penetration Testing Rules of Engagement: AWS, Azure and GCP

• Your Cloud Provider's SOC 2 Report Is Not Your Cloud Pentest Evidence and Cloud and Kubernetes Penetration Testing: Scope and Cost

• Cloud Security Statistics 2026 and The State of Penetration Testing 2026

• Stingrai services: Cloud Penetration Testing, Red Teaming, Web Application Penetration Testing

References

1. Google Cloud. Cloud Threat Horizons Report H1 2026. 2026. https://cloud.google.com/security/report/resources/cloud-threat-horizons-report-h1-2026. Mandiant incident response and managed defense data for H2 2025: identity issues behind initial access in 83% of cloud and SaaS incidents; initial access vectors into Google Cloud workloads; OIDC-linked CI roles as an attack path.

2. Cloud Security Alliance. Top Threats to Cloud Computing 2026. Released 12 August 2026. https://cloudsecurityalliance.org/artifacts/top-threats-to-cloud-computing-2026. Survey-based ranking of cloud threats; inadequate identity and access management ranks first.

3. Datadog. State of Cloud Security. October 2025. https://www.datadoghq.com/state-of-cloud-security/. Telemetry collected September 2025: IAM access key age, IMDSv2 enforcement, Kubernetes API server exposure and node role privileges.

4. Amazon Web Services. Penetration Testing: Customer Support Policy for Penetration Testing. https://aws.amazon.com/security/penetration-testing/. Permitted services, prohibited activities and the Simulated Events process.

5. Microsoft. Penetration testing (Azure security fundamentals). Updated 15 May 2026. https://learn.microsoft.com/en-us/azure/security/fundamentals/pen-testing. No pre-approval since 15 June 2017; summary of the Microsoft Cloud Unified Penetration Testing Rules of Engagement.

6. Google Cloud. Cloud Security FAQ. https://support.google.com/cloud/answer/6262505. No requirement to contact Google before testing your own Cloud infrastructure; tests must only affect your own projects.

7. Center for Internet Security. CIS Benchmarks for Amazon Web Services, Microsoft Azure, Google Cloud Platform and Kubernetes. https://www.cisecurity.org/benchmark/amazon_web_services. Consensus configuration baselines; latest versions listed in October 2026: AWS Foundations 7.1.0, Azure Foundations 6.0.0, Google Cloud Platform Foundation 5.0.0, Kubernetes 2.1.0, EKS, AKS and GKE 2.0.0.

8. Amazon Web Services. Standards reference for Security Hub CSPM. https://docs.aws.amazon.com/securityhub/latest/userguide/standards-reference.html. Supported standards and the statement that controls evaluate and monitor state rather than guarantee compliance.

9. Amazon Web Services. Shared Responsibility Model. https://aws.amazon.com/compliance/shared-responsibility-model/. The division between security of the cloud and security in the cloud.

10. Amazon Web Services. IAM User Guide: passing roles, the confused deputy problem, and OIDC federation. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html, https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html, https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html. Provider guidance behind the identity attack paths and the sample finding's remediation.

11. Microsoft. Overview of enterprise application ownership in Microsoft Entra ID. https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/overview-assign-app-owners. Application owners acting with the application's permissions.

12. Google Cloud. Service account impersonation. https://docs.cloud.google.com/iam/docs/service-account-impersonation. The permission and roles that allow impersonation and what it grants.

13. NIST. Computer Security Resource Center glossary: security assessment; penetration testing. https://csrc.nist.gov/glossary/term/security_assessment and https://csrc.nist.gov/glossary/term/penetration_testing. Definitions used in this guide.

14. Stingrai. The State of Penetration Testing 2026. August 2026. https://www.stingrai.io/blog/state-of-penetration-testing-2026. 55 penetration tests and 1,206 verified findings, October 2024 to August 2026; false positive rate and finding-class splits.