What cloud discovery can and cannot see

A cloud connection here does one job: it lets the platform enumerate the privileged identities in a cloud account you own, so that a question nobody can answer from memory — which accounts in our estate have administrative rights, and which of them does nobody own — has an answer drawn from the accounts themselves rather than from a spreadsheet.

Four providers are offered. One is proven against a live account, two are implemented and have never been run against a real one, and the fourth is not built. That sentence is the reason this article exists, and the difference between those states matters enough that most of what follows is about telling them apart.

The four providers, and the state of each

The distinction in the right-hand column is worth spelling out, because it is easy to read as pedantry and it is not. For AWS, the signature is correct and the enumeration works end to end against AWS are two separate claims, and only the first is currently evidenced. The signing is the part most likely to be wrong and it has been checked hard; what has not been checked is everything after a real AWS endpoint answers — pagination behaviour at scale, an unusual permission shape, an error code we have not seen. If you are the first customer to connect a real AWS account, you are doing the last mile of that verification, and we would rather you knew that than discover it as a support ticket.

One more absence worth naming, because a data model hints at it: an on-premises Active Directory scan type appears in a comment on the scan record and no such scanner is registered. Four scanners exist, and the fourth is the SSH one above.

Storing a credential

Credentials live under privileged access, and the routes sit beneath /organizations/{orgID}/pam/cloud-credentials. The console page is Privileged access › Discovery.

All four are granted to admin only, including the read, and the reasoning recorded in the migration that seeds them is worth understanding rather than working around: a read returns no secret, but it does return which cloud accounts you own and which application identifier and access key identifier the platform authenticates with. That is a target list, and half of a credential pair.

Test is its own permission rather than a read, for the same reason the AI provider's connection test is a write: it makes the platform authenticate outbound into your cloud account. An action with an effect outside the platform is not a read, however little it returns.

In outline, each provider needs a read-only principal of its own: an application registration with a client secret for Entra ID, an access key pair for AWS, and a service-account key for Google Cloud. The scan target is the tenant identifier, the twelve-digit account number, or the project identifier respectively. The credential is envelope-encrypted and there is no path that reads it back — for the exact permissions to grant on each provider, and what the connection test proves, see the privileged-access documentation on storing cloud credentials.

The design choice that matters most: failing rather than returning zero

The Entra scanner refuses to continue if it lacks the directory-role read permission, rather than enumerating what it can and returning a short list. The reason, from the code, is the single best sentence in this subsystem:

Take that as the general rule for reading any result on this page. An empty result is only meaningful if the scan succeeded. A scan that could not authenticate, could not paginate or lacked a permission is a scan that tells you nothing, and the platform is built to say so rather than to present the absence as a finding. The related failure mode across the whole product is covered in Connector health and silent failure.

What each provider does not look at

This is the section to read before you put a discovery result in front of an auditor, because in every case the gaps are places a real privilege can hide. The Entra scanner records its own gaps in the scan metadata as not_covered, which is the behaviour you want; the other two are documented here.

Entra ID does not cover

Application-role assignments held by service principals; Azure RBAC — that is, Owner or Contributor on a subscription or resource group, which is a different system from directory roles; eligible-but-not-active PIM assignments; and narrowing by administrative unit. It also does not enumerate every user, only those holding a role or in a role-assignable group.

AWS does not cover

Inline policies and permissions inherited through a group — a user with administrative rights granted that way is reported as standard with a metadata note saying attachments only, so read the note, not just the level. Also uncovered: permission boundaries and service control policies, IAM Identity Center (SSO) users, and root-account usage.

Google Cloud does not cover

Organisation-level and folder-level bindings — which is where the most powerful grants usually live; Google Group membership expansion; service-account keys; and deny policies and IAM conditions.

How a scan runs, and two things about it worth knowing

A scan is queued, run and then reviewed: you promote a candidate into the vault deliberately rather than having accounts appear there. Scans move through queued, running, then completed or failed. Starting one requires pam:discovery.write; reading scans and candidates requires pam:discovery.read. Both are administrator-only.

Two behaviours that surprise people.

• There is no schedule. A scan happens when somebody starts one, and there is no background job. Whatever you found in March is what the list says until somebody runs it again.
• A scan that cannot run returns a created scan whose status is failed, not an HTTP error. The record exists and is worth keeping, but a client checking only the status code will believe the scan succeeded. Read the status field.

Discovering privileged accounts covers the review-and-promote half of this in detail — the candidate model, what promotion does, and how to build an inventory by hand.

What this connection is not

Three things it does not do, listed because each one is a reasonable guess.

• It is not log collection. A cloud credential stored here does not start ingesting CloudTrail or Entra sign-in logs. Those are separate connections with separate credentials — see Collecting AWS CloudTrail and Collecting Microsoft 365 and Entra logs.
• It is not the Microsoft 365 connection. The posture assessment's read of your Microsoft tenant is a different consent flow with a different permission set — see Connect Microsoft 365.
• It does not change anything in your cloud account. Every call these scanners make is a read. Promotion into the vault is a change in the platform, not in your cloud.

What to do next

1. Start with Entra ID if you have it. It is the one provider whose end-to-end behaviour has been observed against a real tenant, and it is where most privileged identity in a small organisation actually lives.
2. Grant RoleManagement.Read.All before you scan, so that the result is a finding rather than a failure.
3. Read Discovering privileged accounts before promoting anything into the vault.
4. If you connect AWS or Google Cloud, tell us what happened — including if it simply worked. You are closing the one gap in the evidence for those two, and a report either way is genuinely useful. How to get help.