What Access Does a Cloud Penetration Test Need?

Two Phases, Two Kinds of Access

A cloud penetration test has two parts, and they need different access. The configuration review needs read-only visibility, so we can see how your environment is set up. The attack-simulation phase needs one or two deliberately limited accounts, so we can test what a realistic foothold would allow. Nothing in a standard engagement requires administrative write access to your environment, and we agree the exact access in the Statement of Work before testing begins.

Microsoft 365 and Entra ID

For the review, read-only directory and security visibility is enough, typically the Global Reader and Security Reader roles. For the attack phase we work from an authorized list of users and one or two standard, low-privilege test accounts that you create. This lets us safely assess sign-in paths, conditional access, and consent behavior without touching real user data.

• Configuration review: Global Reader plus Security Reader (read-only)
• Attack simulation: an authorized user list and one or two low-privilege test accounts
• No write access to the tenant is required

AWS, Azure, and Google Cloud

For the review, a read-only security-audit role in each account, subscription, or project gives us the visibility we need. For the assumed-breach phase, you provision a single limited, developer-style identity that represents a realistic starting foothold. We escalate from there; we do not start as an administrator.

• AWS: an IAM role with the SecurityAudit and ViewOnlyAccess policies for the review
• Azure: Reader plus Security Reader on each in-scope subscription
• GCP: Viewer plus Security Reviewer on each in-scope project
• Assumed-breach phase: one low-privilege identity you create

Authorization and Provider Policies

Every engagement requires written authorization from your organization and an agreed emergency contact. Testing is scoped to each provider's policy: the major providers permit customers to test their own environments within defined rules, and we stay inside them. We confirm all of this, along with change-freeze windows and any out-of-scope systems, before work starts. For the wider picture, see our guide to cloud penetration testing.

Frequently Asked Questions

Does a cloud penetration test need admin access?

No. The configuration review runs from read-only roles, and the attack-simulation phase uses one or two deliberately low-privilege accounts. A standard engagement does not require administrative write access to your environment. The exact access is agreed in the Statement of Work before testing begins.

What do I need to provide for an AWS, Azure, or GCP test?

For the review, a read-only security-audit role in each in-scope account: SecurityAudit and ViewOnlyAccess in AWS, Reader plus Security Reader in Azure, or Viewer plus Security Reviewer in GCP. For the assumed-breach phase, one limited developer-style identity that you create. Each account, subscription, or project is scoped separately.

What do I need to provide for a Microsoft 365 or Entra ID test?

Read-only roles such as Global Reader and Security Reader for the configuration review, plus an authorized user list and one or two low-privilege test accounts for the attack-simulation phase. No write access to the tenant is required.

Who authorizes the test?

Your organization provides written authorization before any testing begins, and we agree an emergency contact and the testing window. Testing is conducted within each cloud provider's published policy for customer-initiated testing.