A normal access review focuses on users and their entitlements. An integration review focuses on delegated authority, consent scopes, connected systems, and the downstream impact of a compromise. For SaaS estates, that distinction matters because a single app can represent more risk than many individual users.
Why This Matters for Security Teams
An access review and an integration review look similar on paper, but they answer different questions. A normal review asks whether a person still needs a role or entitlement. An integration review asks whether a connected app, API, or delegated consent can be abused to move through SaaS platforms, impersonate trusted workflows, or widen the blast radius of a compromise. That difference matters because the control object changes from the user to the connection itself.
For NHI programs, the risk is often hidden in plain sight. Modern estates contain far more service accounts, API keys, OAuth grants, and automation tokens than human identities, and Ultimate Guide to NHIs explains why visibility and lifecycle control are foundational. OWASP also treats authorization scope, secret handling, and trust in machine identities as core risk areas in the OWASP Non-Human Identity Top 10. The practical point is simple: a clean user access list can still coexist with a dangerously overpowered integration.
In practice, many security teams encounter integration abuse only after an OAuth grant, token, or service connector has already been used to pivot across systems, rather than through intentional review design.
How It Works in Practice
Normal access reviews usually map users to RBAC roles, group membership, and application entitlements. Integration reviews go deeper. They examine what the integration can do on behalf of the business, what data it can read or write, what downstream systems it can call, and whether the consent scope matches the actual business purpose. That is why the review must include delegated authority, secret storage, token lifetime, and any administrative actions the integration can trigger.
Current guidance suggests treating the integration as the identity-bearing object, not just the human who approved it. In NHI terms, that means reviewing the secret, the token issuer, the scope, and the lifecycle together. The Ultimate Guide to NHIs — Key Challenges and Risks highlights why broad privileges and poor visibility amplify exposure, and the NHI Lifecycle Management Guide shows why offboarding and rotation matter as much as initial approval.
- Verify the integration owner, business purpose, and approval trail.
- Check OAuth scopes, API permissions, and admin-consent grants for excess access.
- Confirm secret location, expiration, rotation, and revocation path.
- Map all connected systems and ask what happens if the integration is compromised.
- Test whether monitoring covers token use, not just user logins.
This is also where Zero Trust thinking helps: the connection should be continuously re-evaluated, not permanently trusted after first approval. The OWASP Non-Human Identity Top 10 reinforces that machine identities need explicit lifecycle controls, not just periodic entitlement checks. These controls tend to break down when integrations are tied to legacy SaaS admin accounts because the authority is shared, poorly attributed, and hard to revoke cleanly.
Common Variations and Edge Cases
Tighter integration review often increases operational overhead, requiring organisations to balance stronger containment against release velocity and business convenience. That tradeoff is real, especially in fast-moving SaaS environments where teams rely on many small integrations rather than a few large ones.
Best practice is evolving for cases like partner-connected apps, marketplace add-ons, and automation built with low-code platforms. There is no universal standard for every review cadence or scope threshold yet, but current guidance is to treat any integration with delegated write access, directory privileges, mailbox access, or cross-tenant reach as high risk. For those cases, an access review alone is not enough because the dangerous object is the grant, token, or connector itself.
The 52 NHI Breaches Analysis is useful here because many incidents begin with overly trusted non-human access rather than a simple user entitlement failure. One practical pattern is to pair integration reviews with secret rotation and explicit revocation tests, so the team can prove the integration can actually be shut off. The Ultimate Guide to NHIs – What are Non-Human Identities helps frame why these controls belong in identity governance, not just application inventory.
In edge cases, a normal access review may still be appropriate for the human approver, but the integration review must govern the machine pathway that continues operating after the person leaves or forgets the app exists.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Integration reviews must catch excessive scopes and weak rotation on machine identities. |
| OWASP Agentic AI Top 10 | A1 | Autonomous tool access and delegated authority create the same review gap. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access governance underpins both user and integration reviews. |
Map integrations to least-privilege entitlements and remove excess access during review.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and row-level access in review workflows?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between protecting applications and protecting access?
