Because both tools are authoritative only for the identities they already manage. If an account is never vaulted, never connected, or never modeled in the product, it has no place in that platform’s record and therefore no visibility in its reports.
Why This Matters for Security Teams
IGA and PAM platforms are usually deployed to solve known identity problems: joiner-mover-leaver workflows, privileged account vaulting, and periodic access reviews. The gap appears when the estate includes service accounts, API keys, CI/CD credentials, cloud roles, and other non-human identities that were never onboarded or modeled. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which helps explain why a control can look strong on paper while still missing real exposure.
The problem is not that IGA and PAM are useless. It is that they are authoritative only inside their own inventory boundaries. If an identity is created outside the onboarding path, inherited from a legacy system, embedded in code, or issued by a cloud service, the platform may have no record to govern. That creates blind spots in reporting, certification, rotation, and offboarding. The same pattern shows up repeatedly in breach analysis and in the Top 10 NHI Issues, where unmanaged credentials become the easiest path around otherwise mature identity programmes.
In practice, many security teams discover those blind spots only after an incident forces a manual search for accounts that the official system of record never knew existed.
How It Works in Practice
Existing IGA and PAM tools miss parts of the estate for a structural reason: they depend on discovery sources, connectors, vault enrollment, and human-defined ownership before they can enforce policy. That works reasonably well for employees and a subset of privileged accounts, but it breaks down for distributed machine identities that are created by applications, cloud services, automation pipelines, and third-party integrations. When the identity lifecycle begins outside the platform, the platform never becomes authoritative for that identity.
Practitioners usually see three recurring gaps.
- Discovery gap: the identity exists in a cloud account, repository, secret store, or application, but no connector or scanner is watching that location.
- Modeling gap: the identity is known, but it is classified incorrectly, so it never enters the right access review or rotation workflow.
- Ownership gap: the identity is real, but no business owner or technical owner is assigned, so the record stalls and the control never completes.
That is why the operational answer is broader than “buy better IAM.” Teams need inventory practices that include non-human identities from the start, plus control points that can ingest findings from cloud, code, CI/CD, and secrets stores. NIST Cybersecurity Framework 2.0 is useful here because it pushes organisations to treat asset visibility and governance as an ongoing function, not a one-time onboarding exercise. The same logic is central to the NHI lifecycle guidance in the Ultimate Guide to NHIs: discovery, classification, rotation, and offboarding have to extend beyond the accounts that a legacy platform can already see.
In short, IGA and PAM miss estate segments when those identities are created and used in places the platform does not scan, because no amount of certification can govern what has never been inventoried.
Common Variations and Edge Cases
Tighter identity control often increases operational overhead, requiring organisations to balance full coverage against connector sprawl, ownership disputes, and false positives. That tradeoff is especially visible in hybrid estates, where the same workload may use a cloud-native role, a vault-issued secret, and a hard-coded token left behind in a pipeline.
Current guidance suggests there is no universal standard for this yet, but the practical pattern is clear: treat IGA and PAM as control layers, not as the entire identity estate map. Some environments will also have identities that are intentionally short-lived, externally managed, or federated through a SaaS vendor, which means they may never fit neatly into classic vault-and-certification workflows. Those cases require policy decisions about whether the identity should be inventoried locally, governed through upstream controls, or monitored through compensating detection.
This is where practitioner judgment matters. A platform can be “working as designed” and still miss the most dangerous identities if the design assumptions were human-centric. The most effective programmes pair authoritative identity systems with continuous discovery, asset classification, and exception handling so that shadow credentials, orphaned service accounts, and third-party tokens do not slip through. That is why the NHIMG breach analysis in 52 NHI Breaches Analysis is so instructive: the failure mode is usually not a broken policy, but an identity that was never brought under policy in the first place.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers inventory and discovery gaps for non-human identities. |
| NIST CSF 2.0 | ID.AM-1 | Asset inventory is central to finding identities outside IGA and PAM. |
| NIST Zero Trust (SP 800-207) | PR.AC-1 | Zero trust requires authoritative identity visibility before access decisions. |
| NIST AI RMF | AI RMF governance is relevant when autonomous systems create opaque identity sprawl. | |
| CSA MAESTRO | IA-1 | MAESTRO addresses machine and agent identity governance across control planes. |
Map machine identities to governance owners and enforce lifecycle controls across environments.
