A discovery scan finds nothing
Whether that means you are clean or that nothing looked — and the four causes, starting with the two where an empty result is not a result at all.
A discovery scan returned no candidates. The important question is not why is it empty but whether the empty result means anything, and the answer depends entirely on which of four states you are in.
This matters more than an ordinary troubleshooting question, because an empty candidate list reads as you have no unmanaged privileged accounts when it may mean nothing looked. A false clean bill of health is worse than no scan.
First: read the scan's status, not the candidate count
A scan that could not run does not return an HTTP error. It returns a created scan whose status is failed, carrying a message. So a client that checks only the status code will believe the scan succeeded and found nothing.
Open the scan row and read its Result column. If it says failed, the message tells you the cause and the rest of this article is mostly about interpreting it.
No scanners are configured in this deployment, so discovery cannot run.
Qorionix has no "on_prem_ad" scanner. Supported types are aws, azure, gcp, on_prem_ssh.
The aws scan of "123456789012" did not complete: <underlying error>
The scan found 4 accounts but Qorionix could not record them: <underlying error>That last one is worth noticing: it means the enumeration worked and the storage did not. Four accounts were found and none of them was written. Retry it; if it recurs, tell us.
1. No credential is stored, so the provider cannot scan at all
Three of the four scanners need a credential of yours to sign in with. Without one, the provider is marked Cannot scan yet in the picker before you ever press the button, and the banner above it says exactly what an empty list would mean:
No provider can scan for this organisation yet, so an empty candidate list does not mean you have no unmanaged privileged accounts — it means nothing has looked for them.
Availability is computed per organisation, not per deployment, because the code ships everywhere and the credential does not. Fix: store one. Storing cloud credentials has the exact permissions each provider needs.
2. The credential signs in and cannot read what matters
This is the cause that produces a genuinely misleading result, and it is the reason the connection test is two stages rather than one.
Press Test on the credential row before you scan. The outcome you are looking for is Works, which means both stages passed. Permission denied on a credential that signed in perfectly well is the single most useful thing this feature tells you, and it is invisible if you only ever look at whether the scan ran.
Every test outcome returns HTTP 200, including the failures. A failed test is a result, not an error.
3. You scanned on-premise SSH, which is not implemented
on_prem_ssh is registered, appears in the picker, is marked Cannot scan yet, and returns an error rather than a result. It has never fabricated anything and it is not going to find anything either.
Qorionix cannot scan an on-premise range. This is not something you can configure: the platform has no SSH client, and it runs in Azure with no route to your internal network. The intended path is to have the Qorionix sensor already installed on your network perform the scan, which is not built yet. Starting a scan now records an attempt and finds nothing.
There is no configuration that changes this and no credential you can store to enable it — the on-premise provider is deliberately absent from the cloud-credential form, because a screen that stores a credential for a scanner that cannot use it is a screen that does nothing.
For servers, network devices and everything else inside your perimeter, the inventory is a manual exercise. Discovering privileged accounts has the procedure, and it is shorter than you expect.
There is also no Active Directory scanner. Asking for on_prem_ad fails with the message listing the four types that exist.
4. It worked, and the thing you are looking for is outside what it covers
If the scan says completed and the credential tests clean, the enumeration ran. An empty or thin result then means the privileges in your estate are of a kind this scanner does not read — and each scanner records its own gaps rather than leaving you to infer them.
| Provider | What it will not see |
|---|---|
| Entra ID | Azure RBAC at subscription or resource-group level — so a subscription Owner who holds no directory role is invisible. Also application role assignments, eligible-but-inactive PIM assignments, and administrative-unit scoping. |
| AWS | Inline policies and policies inherited through a group. Only attached managed policies are read, so an account whose administrative rights come from an inline policy is reported as standard rather than admin. Also permission boundaries, service control policies, IAM Identity Center users and root-account usage. |
| Google Cloud | Organisation- and folder-level bindings, Google Group expansion, deny policies and conditional bindings — and service-account key enumeration, which is the fact this product most cares about and is explicitly left for a later pass. |
Read those as and therefore rather than as caveats. An AWS scan returning no administrators does not mean you have none; it means none of them got there through an attached managed policy.
There is also a per-scan request budget on AWS so a large account cannot trip your own IAM rate limit. Principals past the budget are reported with privilege unknown and a note saying the budget was reached — deliberately, rather than being silently downgraded to standard.
How much to trust a result that does come back
Worth knowing, because the three working scanners are not equally proven.
- Entra ID has been run against a live tenant, and there is a live-tenant test that fails if a tenant returns zero privileged principals — on the reasoning that every tenant has at least one Global Administrator, so an empty result means the enumeration is broken rather than that you are clean.
- AWS has been verified against Amazon's published request-signing test vectors and against a server that speaks the real response shape. It has not been run against a live AWS account. The signature is correct and the enumeration works end to end are two claims and only the first is evidenced.
- Google Cloud is in the same position: exercised against a protocol-shaped fake, never against Google.
So if an AWS or GCP scan returns something surprising — nothing at all, or obviously too little — you may be the first person to run it against a real account, and we would genuinely like to hear about it. Send us the scan id.
If you cannot start a scan at all
Reading scans and candidates needs pam:discovery.read; starting one and onboarding a candidate need pam:discovery.write. Neither is granted to member or viewer, and the reason is the same as for targets: a candidate list names real hosts and the privileged accounts on them.
The cloud-credential panel is separately gated, and it explains itself rather than showing an empty list — Cloud credentials are administrator-only… This is not a statement that none are stored — ask an administrator. A 403 insufficient permissions here is a role problem; see Insufficient permissions.
Two smaller things that look like emptiness
- A scan runs inside the request that starts it, with a four-minute ceiling and no queue. A large account can time out; the scan is recorded as failed with the underlying error rather than as an empty success.
- Discovery does not run on a schedule. It happens when somebody starts one. A candidate list that has not changed in a month has not been re-checked in a month.