Should organisations prioritise transaction governance or access certification first?

Why This Matters for Security Teams

The real decision is not whether to abandon access certification, but whether static entitlement reviews are the right first control for the workflows that matter most. If a process can trigger payments, post journal entries, approve exceptions, or mutate master data, then proving what happened is often more valuable than proving who could have done it. That is why transaction governance belongs ahead of blanket certification in high-impact systems, while certification still remains necessary for baseline accountability.

This distinction matters because NHIs rarely behave like humans with stable job roles. They are tied to services, scripts, pipelines, and integrations that can change behaviour faster than quarterly reviews can keep up. The risk is not just excess access, but unmonitored execution. Top 10 NHI Issues and the Ultimate Guide to NHIs — Key Challenges and Risks both show how credential sprawl, over-privilege, and poor observability compound each other. NIST’s NIST Cybersecurity Framework 2.0 reinforces the need to detect and respond to risky activity, not just document access on paper.

In practice, many security teams discover entitlement gaps only after an approval chain, posting job, or API-driven workflow has already produced the wrong outcome.

How It Works in Practice

Start by ranking systems by business impact, not by how easy they are to review. The first candidates for transaction governance are systems where a single action can create financial, regulatory, or operational harm. That usually means ERP postings, payment approvals, privileged integrations, data exports, and any workflow where an NHI can act without a human in the loop. Access certification still matters, but it becomes the secondary control for proving who is supposed to hold access rather than proving that every use of access was appropriate.

Effective transaction governance combines logging, policy checks, and exception handling. At minimum, teams should bind each sensitive action to a workload identity, record the approval context, and retain an audit trail that is resistant to tampering. The operational question is not only “did the account exist?” but “was this action expected, approved, and consistent with policy?” That is aligned with the lifecycle and audit focus in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the audit emphasis in Ultimate Guide to NHIs — Regulatory and Audit Perspectives.

• Use access certification for standing entitlements, service ownership, and periodic clean-up.
• Use transaction governance for posting, approval, and data-change actions that carry immediate impact.
• Require strong workload identity and short-lived secrets where possible, so the actor is identifiable at execution time.
• Evaluate policy at runtime for the specific action, not just at onboarding.

That operating model lines up with the control intent in the OWASP Non-Human Identity Top 10, especially where over-privilege and weak lifecycle discipline create avoidable exposure. These controls tend to break down in legacy ERP and mainframe environments because transaction logs are incomplete, identities are shared, and approval context is not captured consistently.

Common Variations and Edge Cases

Tighter transaction governance often increases friction, so organisations must balance stronger assurance against process speed and user experience. That tradeoff is real, especially in high-volume finance, operations, or DevOps pipelines where excessive approval steps can create workarounds. Best practice is evolving, but there is no universal standard for how much transaction control is “enough” in every environment.

One common edge case is low-risk automation with high-volume, low-value actions. In those environments, full transaction review can create more noise than value, so a lighter certification-first model may be acceptable. Another is shared platform accounts, where access certification is weak by design because the identity is not uniquely attributable. In those cases, governance has to shift toward stronger workload identity, better logging, and tighter segregation of duties. The question is not whether certification disappears, but whether it is sufficient on its own. It rarely is for sensitive execution paths.

For teams mapping this to broader NHI programme work, the practical takeaway is to start with the workflows that can cause the most harm, then expand control coverage outward. The 52 NHI Breaches Analysis and the Sisense breach are useful reminders that governance failures often emerge where access looks legitimate but execution is not sufficiently constrained.

Related resources from NHI Mgmt Group

• Should organisations prioritise external exposure or internal credential governance first?
• Should organisations prioritise compliance certification or access evidence first?
• What is the difference between role-based access and API key governance for NHI security?
• Should organisations prioritise secret rotation or access review first