What a read-only Azure security assessment can prove
A read-only Azure security assessment, run with Global Reader in Entra ID and Reader at subscription scope, proves what the tenant is configured to do. It shows who holds which privilege, which conditional access policies apply to which accounts, what the control plane exposes to the internet, where secrets are meant to live, and whether telemetry is being collected. It does not prove that a control holds against an attempt, or that the software behind an open port is safe. Those questions need a credentialled or attacker-perspective test. The read-only phase establishes those facts without changing the environment and identifies which findings warrant testing.
Which roles the read-only phase needs
Global Reader in Entra ID, and Reader at the subscription or management group scopes under review; both read the control plane only. Global Reader returns directory objects, role assignments, conditional access policies, app registrations with their credential metadata, authentication method settings, and the sign-in and audit logs. Reader returns the Azure Resource Manager configuration of every resource in scope that a read request exposes: role and policy assignments, network security groups, storage account settings, Key Vault configuration, diagnostic settings, and the Defender for Cloud assessments and secure score.
Neither role reads data. Reader does not return storage account keys, Key Vault secret values, database contents, or the values of App Service application settings, because each sits behind a list action or a data-plane permission that Reader does not hold. That boundary lets the assessment run against a production tenant without a change window, and the Entra sign-in logs record each sign-in the assessor's account makes.
The scope of the Reader assignment sets what the assessment can see. Reader at one subscription shows role assignments within that subscription only. A managed identity that holds Owner in a second subscription is invisible unless Reader is assigned there too, or at a management group containing both. Scoping records which subscriptions are in review so the assignment covers the whole estate.
What read-only configuration evidence establishes on its own
Each row settles a claim the tenant owner can verify with the same role.
A finding in any of these rows carries its evidence: the resource identifier, the property, its value, and the time it was read.
| Control area | Evidence read-only access yields | What that evidence settles |
|---|---|---|
| Privileged roles | Active and eligible Entra ID role assignments; Owner and Contributor at subscription and resource group scope, with identity, scope and assignment date | Which identities hold standing privilege, at what scope, and whether each assignment matches a job the tenant can name |
| Conditional access | Every policy with its state, included and excluded users, groups and applications, and grant controls | Whether administrative accounts are inside a multi-factor requirement, and which accounts sit in an exclusion group |
| Legacy authentication | The policy blocking legacy protocols, and sign-in log entries showing which client applications still attempt them | Whether legacy authentication is blocked, and which workloads would break when it is |
| Service principals | Client secrets and certificates per app registration with expiry dates, and any federated identity credentials | Which principals carry long-lived secrets, which use workload identity federation, and which secrets never expire |
| Guest and dormant accounts | Sign-in activity per account where the tenant's Entra licence exposes it, guest inventory, cross-tenant access settings | Which accounts have not authenticated within the window agreed at scoping |
| Network exposure | Network security group rules, public IP inventory, the public network access setting on storage, database and Key Vault resources, private endpoint inventory | What the control plane says is reachable from the internet, and where a private endpoint exists while the public path stays open |
| Secrets handling | Key Vault permission model, soft delete and purge protection, managed identities on workloads, federated credentials on deployment identities | Whether the tenant has the machinery for secretless deployment, and which identities can read vault contents |
| Logging | Diagnostic settings per resource, activity log export, Log Analytics workspace retention, sign-in log retention | Whether telemetry exists for each resource, where it lands, and how long it survives |
| Workload configuration | Storage minimum TLS version, shared key access and anonymous blob access; database firewall rules; container platform ingress settings | Whether resource-level settings match the platform's hardening guidance |
What read-only configuration evidence establishes on its own
Where configuration evidence ends and testing begins
Configuration evidence records what a control is set to do; a test records what happens when an account or an unauthenticated caller pushes on it.
A conditional access policy that requires multi-factor authentication for administrators, with an exclusion group holding the break-glass accounts, is a fact. Whether those accounts carry a password that would withstand a password spray is not visible in any setting, and is tested only where the scoping record permits it. A network security group rule permitting inbound traffic on a port from any source is a fact. Whether the service listening behind it authenticates callers, and whether it is patched, is a property of the running software. A storage account with public network access enabled and anonymous blob access disabled is a fact. Whether a shared access signature for that account was pasted into a client-side bundle several deployments ago is not in the tenant.
Some evidence sits past the Reader boundary and is agreed at scoping. Application setting values on App Service and Function Apps need a list action, so the tenant exports them or grants the action on named resources for the review window. Secret created, updated and expiry dates in Key Vault need the data-plane Key Vault Reader role on vaults using the RBAC permission model, or a read-only access policy on older vaults; both return metadata and not values. Pipeline variables and repository contents live outside Azure and need access to the source control platform.
Which findings need a credentialled or attacker-perspective test
A finding that describes a path, a sequence of steps an account could take, needs a test before it is rated.
Privilege escalation through managed identities. Read-only access shows a user holding Contributor on a virtual machine, and the machine's system-assigned identity holding Owner on a resource group elsewhere. Together the two facts describe a path: a command run on the machine can request a token for its identity and use it with Owner rights. Whether that path is open in practice is proved by walking it from a low-privilege account the tenant issues for the test.
Directory defaults. Global Reader shows whether members can register applications, consent to applications, and read the full directory. A credentialled test from a standard user account shows what that user can enumerate and which consent prompts they can approve. The settings to read first are in app consent and service principals in Entra.
Internet-facing services. The network exposure inventory produces a list of public endpoints. An external test against that list establishes what each endpoint does for an unauthenticated caller: an App Service with platform authentication off, a Function App with an anonymous HTTP trigger, a storage container that lists its contents. That list is the starting scope for an external penetration test, and for attack surface monitoring once the baseline is known.
Guest and cross-tenant paths. Cross-tenant access settings are readable. What a guest from a partner tenant can open is proved from a guest account, and guest access and cross-tenant access in Entra sets out the settings to check before the test.
How severity changes once tenant context is added
Public network access enabled on a storage account serving a static website's assets is recorded as a low finding. The same setting on the account receiving nightly database exports goes near the top of the remediation plan.
The scoping record states which subscriptions are production, which workloads hold regulated data, and what the organisation must answer for: health records under the Privacy Act, the obligations that attach to an Australian Financial Services Licence, or the controls a government contract calls up. Aurii, the clinical software platform the firm built and operates, runs on Container Apps in Australia East with PostgreSQL row-level security isolating tenant health data, and client tenants are read with the same question in mind: what sits behind this setting, and what the consequence of its failure would be.
Each finding records the setting, the evidence, the asset behind it and the reason for its rank, so remediation starts with the changes that remove the most exposure.
How to grant the access before the assessment starts
Each step leaves a record in the Azure activity log or the Entra audit log.
1. Create a dedicated cloud-only account for the assessor, with a named internal owner and an agreed end date. Do not lend an existing administrator's credentials. 2. Leave the account inside every conditional access policy that covers administrators, with no exclusion. 3. Assign Global Reader in Entra ID. Where Privileged Identity Management is licensed, make the assignment eligible with activation, or active with an expiry matching the engagement. 4. Assign Reader at the management group covering the in-scope subscriptions, or at each subscription individually, and record the scope. 5. Decide how application settings, pipeline variables and Key Vault metadata will be evidenced: an export, a screen-shared session, or a scoped grant on named resources. 6. Confirm the assignments appear in both logs. 7. When the engagement ends, remove the role assignments and disable the account. The same logs record the removal.
What to send when you scope the work
Scope, timeframe and deliverable are fixed before any access is granted, from a brief that covers:
Black Shard holds SMB1001:2026 Gold and self-assesses against the ASD Essential Eight at Maturity Level 2, so findings map to those frameworks where the brief calls for it. The page that does this work is the Azure security review. Send the brief to info@blackshard.com.au, and the scope proposal names the exact roles and scopes to assign.
- The tenancy layout: management groups, subscriptions, and which are production.
- The workloads that matter: the platforms and applications, where their data lives, and which data is regulated.
- The identity estate: users, guests, service principals, and the roles administrators hold.
- Obligations: Essential Eight, SMB1001, ISO 27001, the Privacy Act, and any contract clause or insurer requirement.
- What already runs: Defender for Cloud, a Log Analytics workspace, Azure Policy assignments, and the current secure score.
- Prior findings, incidents, and remediation still in flight.
- Who receives the findings report and remediation plan.