The programme loses precision. Controls, evidence, and capital treatment stay tied to the company structure even when the regulatory obligation depends on a specific service such as fund transfers or payment gateway activity, which creates gaps in audit readiness and risk ownership.
Why This Matters for Security Teams
Entity-based compliance assumes the organisation chart is the right unit of control. That works for headcount, but it breaks for regulated activity where the obligation follows a service, workflow, or transaction type. A payment gateway, fund transfer rail, or delegated API action can trigger controls even when the legal entity stays unchanged. Current guidance in NIST Cybersecurity Framework 2.0 points teams toward outcome-focused governance, while NHIMG research shows why identity boundaries alone are not enough.
When compliance stays tied to the entity, evidence collection becomes fragmented, control ownership gets misplaced, and remediation is delayed because teams chase the wrong scope. That creates audit gaps where the service is in scope but the supporting control set sits outside the reporting line. In practice, many security teams encounter the mismatch only after an audit finding, a regulatory inquiry, or a control failure has already exposed the gap.
How It Works in Practice
Activity-based compliance maps obligations to what the system actually does, not just who owns it. For NHI and agentic environments, that means tracing controls to a specific workload, API, workflow, or event class. The best starting point is to inventory regulated activities, then bind each one to the credentials, secrets, approvals, logs, and retention rules that support it. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives frames this as a governance problem, not just a tooling problem.
In practice, teams should separate three layers:
-
Entity layer: legal entity, business unit, or parent company for ownership and reporting.
-
Activity layer: the regulated service, such as fund transfer initiation, payment authorisation, or customer data export.
-
Identity layer: the NHI, service account, API key, certificate, or agent credential that performs the activity.
This structure lets audit evidence follow the transaction path. It also supports control testing at the right granularity, so reviewers can verify whether a payment action used approved credentials, whether logs were retained for the right event class, and whether revocation happened after the task completed. The lifecycle view in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is especially useful here because the obligation often changes at creation, use, rotation, and offboarding rather than at entity reorganisation.
For programme design, compliance teams should ask which activities create regulatory exposure, which NHIs can execute them, and what proof exists at the moment of execution. That usually means policy-as-code for eligibility, event logging for proof, and ownership assignments that sit with the service operator rather than a generic corporate control function. These controls tend to break down when a shared platform serves multiple regulated products because the same NHI can support different obligations with different retention, approval, and segregation requirements.
Common Variations and Edge Cases
Tighter activity-based control often increases operational overhead, requiring organisations to balance audit precision against implementation complexity. That tradeoff is real: the more granular the mapping, the more evidence streams, control exceptions, and ownership rules must be maintained.
Guidance is still evolving for shared services, outsourced processors, and multi-tenant platforms. There is no universal standard for how to split compliance ownership when one NHI supports both regulated and unregulated activity. Some teams apply the strictest applicable control to the whole service; others segment by transaction class or customer segment. The right choice depends on the regulator, the contract, and the evidence model.
Edge cases also appear when automation chains activities together. A single agent or workflow may authenticate once, then trigger multiple downstream actions across payment, reporting, and reconciliation systems. In that environment, entity-based compliance misses the control point because the obligation attaches to the activity chain, not the corporate boundary. In practice, that is where Top 10 NHI Issues becomes operationally relevant: excessive scope, weak lifecycle control, and unclear ownership are what turn a tidy org chart into a weak assurance model.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Outcome-based oversight fits activity-based compliance better than entity-only controls. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Activity scope affects NHI rotation, revocation, and evidence tied to service use. |
| NIST AI RMF | AI RMF supports governance by function and impact, not just legal entity boundaries. |
Classify controls by the activity's risk and impact, then assign accountability accordingly.
