Give an auditor read-only access to AWS, Azure, or GCP safely

TL;DR — To give an auditor safe access, create a separate account for them, attach your cloud provider's built-in read-only role/policy, and require MFA (multi-factor authentication, a code from an app or device). The most common fix is: do not reuse an admin login or a shared team account; create a dedicated auditor identity with read-only permissions only. Reading time: ~5 min

Goal

When you finish, your auditor will be able to sign in to your cloud provider and view your infrastructure, logs, and configuration in the dashboard, but they will not be able to create, edit, delete, or stop resources.

Prerequisites

• Your cloud provider admin login for one of these platforms: AWS, Microsoft Azure, or Google Cloud
• Permission to manage identities and access in that cloud account/subscription/project
• The auditor's email address
• A phone number or authenticator app for MFA if your provider asks you to enroll it during setup
• If you use command line tools instead of the dashboard:
  • AWS CLI v2 — check with:

aws --version

• Azure CLI 2.x — check with:

az version

• Google Cloud CLI — check with:

gcloud version

Steps

Step 1: Decide which cloud account the auditor needs

Use this rule before you click anything:

• If all your systems are in one cloud account/subscription/project, grant access there.
• If your production and non-production systems are separate, grant access only to the production account if that is what the audit covers.
• If you use more than one cloud provider, repeat the matching section below for each one.

What you should see when this step succeeds: you know the exact AWS account, Azure subscription/resource group, or GCP project/folder the auditor needs to review.

Step 2: Create a dedicated auditor identity in your provider dashboard

Pick the section for your cloud provider.

AWS

Menu path in the AWS console:

• AWS Console → IAM → Users → Create user

Literal values to enter:

• User name: auditor-<company>-<yyyy-mm>
• Console access: Enabled
• Password option: Autogenerated password
• Require password reset: Enabled

Then attach permissions:

• Permissions options: Attach policies directly
• Policy to attach: ReadOnlyAccess

Then enable MFA after the user is created:

• IAM → Users → auditor-<company>-<yyyy-mm> → Security credentials → Multi-factor authentication → Assign MFA device

What you should see when this step succeeds: the new IAM user shows the ReadOnlyAccess policy, and the Security credentials page shows MFA as enabled.

Azure

Menu path in the Azure portal:

• Azure Portal → Microsoft Entra ID → Users → New user → Create new user

Literal values to enter:

• User principal name: auditor-<company>-<yyyy-mm>@<your-tenant>.onmicrosoft.com
• Display name: Auditor <Company> <YYYY-MM>
• Auto-generate password: Yes

Then assign read-only access:

• Azure Portal → Subscriptions → <your subscription> → Access control (IAM) → Add → Add role assignment
• Role: Reader
• Assign access to: User, group, or service principal
• Select: the new auditor user

If the audit is limited to one resource group instead of the whole subscription:

• Azure Portal → Resource groups → <your resource group> → Access control (IAM) → Add → Add role assignment
• Role: Reader
• Select: the new auditor user

What you should see when this step succeeds: the user appears in Entra ID, and the Role assignments list shows Reader for the correct subscription or resource group.

Google Cloud

Menu path in the Google Cloud console:

• Google Cloud Console → IAM & Admin → IAM → Grant access

Literal values to enter:

• New principals: the auditor's email address
• Role: Viewer

If your audit covers billing too, add one more role:

• Google Cloud Console → IAM & Admin → IAM → Grant access
• New principals: the same auditor email
• Role: Billing Account Viewer

If your organization uses folders and the audit is broad, grant at the folder level instead:

• Google Cloud Console → IAM & Admin → IAM on the correct folder → Grant access → Role Viewer

What you should see when this step succeeds: the IAM list shows the auditor email with the Viewer role on the correct project or folder.

Step 3: Send the login details securely

Send the auditor only the minimum they need:

For AWS, send:

• AWS account sign-in URL from IAM → Dashboard or the user creation summary
• Username: auditor-<company>-<yyyy-mm>
• Temporary password, sent separately from the URL if possible

For Azure, send:

• Portal URL:

https://portal.azure.com/

• Username you created
• Temporary password

For Google Cloud, send:

• Console URL:

https://console.cloud.google.com/

• Confirm the exact Google account email you granted access to

What you should see when this step succeeds: the auditor confirms they received the sign-in URL and username, and they can reach the login page.

Step 4: Require MFA before the auditor starts reviewing

If your provider lets you enforce MFA by policy, do that. If not, walk the auditor through MFA enrollment at first login.

Recommended dashboard paths:

• AWS: IAM → Users → <auditor user> → Security credentials → Multi-factor authentication
• Azure: Microsoft Entra ID → Users → <auditor user> → Authentication methods
• Google Cloud: enforce 2-Step Verification in your Google Workspace or Cloud Identity admin console if you manage the account there

What you should see when this step succeeds: the account shows MFA enabled, or the auditor confirms they enrolled an authenticator app and can sign in with a code.

Step 5: Verify the account is read-only by testing one blocked action

Have the auditor sign in and open a harmless resource page, then try one action that should be blocked.

Examples of safe blocked-action tests:

• AWS: open EC2 → Instances → select an instance → click Stop instance and cancel before any confirmation; access should be denied before the action can proceed
• Azure: open a virtual machine → try Stop; the portal should show an authorization error
• GCP: open Compute Engine → VM instances → try Stop; the UI should show a permission error

What you should see when this step succeeds: the auditor can list resources and open details pages, but any create/edit/delete/stop action is denied.

Verify it works

Use these checks end to end:

1. The auditor can sign in to the correct cloud dashboard.
2. The auditor can open at least one compute resource, one storage resource, and the IAM/identity page.
3. A write action is blocked with an authorization error.

Expected results by provider:

• AWS: resource lists load, and write attempts show is not authorized to perform
• Azure: resource pages load, and write attempts show does not have authorization
• GCP: resource pages load, and write attempts show Permission denied

This is the access pattern you want:

[Auditor] ---- 1. sign in + MFA ----> [Cloud Console]
[Cloud Console] ---- 2. view resources ----> [Your Account]
[Auditor] ---- 3. try stop/delete ----> [Cloud Console]
[Cloud Console] ---- 4. permission denied ----> [Auditor]

Common pitfalls

Giving the auditor an admin or shared team account

Mistake: using an existing owner/admin login because it is faster.

Symptom: the auditor can change resources, or your activity logs show actions under the wrong person.

Fix: create a new dedicated user for the auditor and attach only ReadOnlyAccess, Reader, or Viewer.

Granting access at the wrong scope

Mistake: assigning the role on the wrong AWS account, Azure subscription/resource group, or GCP project/folder.

Symptom: the auditor signs in but sees no resources, or sees only part of the environment.

Fix: re-open the role assignment and attach it at the exact account/subscription/project/folder that contains the audited systems.

Forgetting billing visibility when the audit includes costs

Mistake: granting infrastructure read-only access but not billing read-only access.

Symptom: the auditor can inspect servers and storage but cannot open cost or invoice pages.

Fix: add your provider's billing read-only role as a second assignment if the audit requires financial review.

MFA not enrolled before the handoff

Mistake: sending credentials before MFA is set up or explained.

Symptom: the auditor gets stuck at first login or cannot complete sign-in.

Fix: enable MFA on the account first, then send the sign-in URL and stay available for the first login if needed.

Access changes do not appear immediately in an open browser tab

Mistake: testing right after changing roles while the auditor still has an old session open.

Symptom: the auditor still sees access denied, or still sees options they should not have.

Fix: have the auditor sign out completely, close the browser tab, sign in again, and re-test.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.