Can-do analysis evaluates whether an identity has the entitlement to perform conflicting actions, regardless of whether those actions have occurred. It is the standard SoD detection model and the starting point for deciding whether access should be remediated or accepted with mitigation.
Expanded Definition
Can-do analysis is the control logic used to determine whether an identity can perform a pair, or chain, of conflicting actions even when no suspicious action has yet occurred. In NHI governance, it is the standard way to detect Segregation of Duties exposure by comparing effective entitlements, not event history. That makes it more proactive than incident review and more precise than simple role inventory. It is especially important where service accounts, pipelines, and AI agents inherit broad permissions through groups, roles, or delegated access. In practice, can-do analysis asks whether the identity has the theoretical ability to create, approve, deploy, export, or revoke in combinations that should not coexist. This is closely aligned with least privilege concepts in the NIST Cybersecurity Framework 2.0, although no single standard governs the term itself and usage across vendors still varies.
For NHI programs, the key distinction is between what an identity has done and what it could do right now if misused, compromised, or repurposed. The most common misapplication is treating can-do analysis like audit logging, which occurs when teams wait for a conflicting action to appear in logs instead of evaluating standing entitlement combinations.
Examples and Use Cases
Implementing can-do analysis rigorously often introduces entitlement-mapping overhead, requiring organisations to weigh earlier conflict detection against the cost of maintaining accurate permission graphs.
- A CI/CD service account can both approve a deployment and push code to the same release path, creating a self-approval conflict that should be flagged before production promotion.
- An AI agent can read customer records and also export data to external tools, which creates a segregation risk even if the export action has never been used.
- A privileged automation identity can create a secret, retrieve it, and rotate it without independent approval, which weakens control separation and complicates evidence collection.
- An access review finds that a platform role grants both provisioning and deprovisioning rights across the same application, so Ultimate Guide to NHIs guidance would treat that as a governance issue, not just a design quirk.
- In a Zero Trust environment, an identity may be authenticated correctly yet still remain over-entitled, which is why can-do analysis complements NIST Cybersecurity Framework 2.0 access discipline rather than replacing it.
Why It Matters in NHI Security
Can-do analysis matters because NHI failures often stem from dormant privilege, not overt misuse. When identities outnumber humans by 25x to 50x and 97% of NHIs carry excessive privileges, the attack surface becomes defined by what each identity is able to do, not just what it has recently done. That is why NHI Management Group treats entitlement conflict detection as a foundational governance step, especially in environments where secrets, service accounts, and agentic workflows are spread across code, CI/CD, and cloud control planes. The Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which makes can-do analysis difficult but also more necessary. The control question is not only whether access exists, but whether the access creates a conflicting path to abuse, fraud, or unauthorized change.
Practitioners typically encounter the need for can-do analysis only after a breach review reveals that an identity could have combined harmless-looking permissions into a damaging action, at which point the term becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Can-do analysis detects conflicting NHI entitlements before abuse or SoD failure. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access review requires checking what an identity can do, not only what it did. |
| NIST Zero Trust (SP 800-207) | Zero Trust limits trust in identity claims and privileges, supporting entitlement conflict analysis. |
Map effective permissions to SoD conflicts and remediate identities that can perform incompatible actions.
