Accountability sits with the organisation that sets the authentication policy, defines the transaction thresholds, and accepts the residual fraud risk. Security, fraud, identity, and compliance teams should jointly decide what level of proof is required for sensitive actions, then monitor exceptions, audit trails, and post-transaction outcomes to show that the control is working as intended.
Why This Matters for Security Teams
When a risky transaction goes through with weak identity evidence, the failure is rarely just technical. It is usually a governance problem that spans authentication policy, fraud thresholds, approval workflows, and exception handling. The accountable party is the organisation that accepted the risk, but the practical burden is shared across identity, security, fraud, and compliance functions. If those teams do not agree on evidence standards, the control becomes a paper exercise.
This matters because modern identity systems are expected to support both prevention and defensibility. Security teams need to show not only that a transaction was blocked or approved, but also why the decision was reasonable at the time. NIST’s Cybersecurity Framework 2.0 frames this as governance and risk management, while NHIMG’s Ultimate Guide to NHIs shows how weak visibility and excessive privilege turn identity gaps into operational loss. In the 2024 ESG report, Oasis Security & ESG found that 72% of organisations have experienced or suspect a breach of non-human identities, which is a reminder that identity evidence failures are not theoretical.
In practice, many security teams encounter accountability gaps only after an approved transaction is later disputed, rather than through intentional control testing.
How It Works in Practice
Accountability starts with policy design. The organisation must define what counts as enough identity evidence for a given action, including step-up authentication, transaction limits, device posture, session age, behavioural signals, and privileged approval paths. Those decisions should be explicit, documented, and mapped to business risk rather than treated as default settings.
At execution time, the control should evaluate identity evidence in context. That means combining authentication strength with the value, destination, sensitivity, and abnormality of the transaction. For human users, this often means step-up verification when risk rises. For non-human identities, it often means tighter workload identity, short-lived credentials, and request-time policy checks. NIST SP 800-53 Rev. 5 supports this style of control by requiring access enforcement, auditability, and least privilege, while NHIMG’s Top 10 NHI Issues highlights how overprivileged identities and poor rotation create silent approval risk.
- Set transaction thresholds by risk tier, not by one-size-fits-all policy.
- Require stronger identity proof for irreversible, high-value, or externally facing actions.
- Log the evidence used in each approval so reviewers can reconstruct the decision.
- Track overrides and exceptions separately so they do not disappear into normal approvals.
- Review post-transaction losses, disputes, and false approvals to recalibrate policy.
The core question is not whether a transaction was approved, but whether the approver had enough trustworthy evidence to justify that approval. That evidence should be proportional to the consequence of failure, and it should be evaluated at the moment of decision. These controls tend to break down in high-volume automated environments because rigid approval rules cannot keep pace with changing risk signals and delegated authority chains.
Common Variations and Edge Cases
Tighter identity proofing often increases friction, audit burden, and customer drop-off, so organisations must balance strong assurance against operational velocity. There is no universal standard for this yet, especially where fraud, privacy, and availability goals compete. Current guidance suggests using layered controls rather than relying on a single identity check.
One common edge case is delegated approval. If a manager, bot, or service account approves a transaction on behalf of someone else, accountability becomes shared across the delegation policy, the approver, and the team that set the workflow. Another is compensating control design: a weak initial identity signal may be acceptable if paired with transaction monitoring, delayed settlement, or mandatory out-of-band confirmation. NIST CSF 2.0 supports this kind of risk-based governance, and NHIMG’s 2024 ESG Report: Managing Non-Human Identities is a useful reminder that identity failures often persist because teams assume another function owns the risk.
For regulated industries, the practical answer may also be shaped by sector rules, contractual obligations, and internal loss-tolerance. The safest operational model is to define who owns the policy, who can override it, who reviews exceptions, and who reports residual risk to leadership. That structure matters most when identity evidence is partial, because the system will otherwise default to convenience over assurance.
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 SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Governance clarity is central when identity evidence is insufficient. |
| NIST SP 800-53 Rev 5 | AC-2 | Accountability depends on controlled accounts and approval boundaries. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Weak NHI governance can let privileged transactions proceed without adequate proof. |
| CSA MAESTRO | GOV-01 | Agent and workflow accountability requires explicit governance of autonomous approvals. |
| NIST AI RMF | Risk governance and accountability apply to AI-driven approval decisions. |
Establish human accountability, monitoring, and escalation paths for risky AI-assisted approvals.
Related resources from NHI Mgmt Group
- Who is accountable for wallet trust when organisations rely on certified identity wallets for access decisions?
- How should security teams implement decentralized identity without creating new trust gaps?
- What breaks when organisations try to scale identity federation without fixing ownership and fragmentation problems?
- When does a machine identity become a compliance problem?
