By NHI Mgmt Group Editorial TeamPublished 2026-06-03Domain: EventsSource: Pathlock

TL;DR: Traditional access management answers who can act, but ERP and business-critical environments increasingly need proof that each transaction was appropriate, continuous, and compliant, according to Pathlock’s webinar on Nexus. The governance gap is shifting from access certification to transaction-level assurance, especially where AI widens compliance blind spots.


At a glance

What this is: This webinar argues that identity governance must move from certifying access to certifying transactions, with continuous evaluation across ERP and business-critical applications.

Why it matters: It matters because IAM, IGA, PAM, and compliance teams need controls that prove execution is appropriate, not just permitted, across human, NHI, and AI-influenced workflows.

By the numbers:

👉 Register for Pathlock’s live webinar on certified transaction governance


Context

Continuous transaction governance is the idea that control should be evaluated at the point of execution, not only when access is granted. In ERP and business-critical systems, that matters because a user or service may be authorised in general but still perform a specific action that is out of policy, out of sequence, or impossible to justify after the fact. This webinar frames certified transaction as the missing layer in identity governance.

That shift is especially relevant where access reviews, role design, and compliance checks have not kept pace with AI-assisted work or complex ERP estates. For teams building modern identity programmes, the question is no longer only who has access, but whether the system can continuously prove that each transaction was appropriate. The Ultimate Guide to NHIs is useful background for the governance patterns behind that problem.

Pathlock presents this as a practical governance problem rather than a pure security theory. The starting point is typical for large enterprises running multiple business-critical applications, where certification alone rarely answers audit, fraud, or separation-of-duties concerns at transaction speed.


Key questions

Q: How should security teams govern high-risk ERP transactions beyond access reviews?

A: Security teams should separate entitlement from execution. Access reviews confirm who can act, but high-risk ERP transactions need runtime evidence that the specific action was appropriate, approved, and traceable. That usually means mapping sensitive workflows, defining policy checkpoints, and retaining proof of the decision path for audit and fraud review.

Q: Why do traditional IAM controls fall short in multi-ERP environments?

A: Traditional IAM controls often stop at provisioning, role design, and periodic recertification. Multi-ERP estates create inconsistent local workflows, delegated approvals, and action paths that can satisfy access policy while still failing business policy. The gap is in execution visibility, not just account control.

Q: What breaks when compliance is measured only at the access layer?

A: What breaks is the ability to prove that a specific transaction was acceptable at the time it happened. Access-layer measurement can show entitlement, but it cannot reliably explain an exception, an override, or an AI-assisted decision after the fact. That creates weak audit evidence and blind spots in separation-of-duties enforcement.

Q: Should organisations prioritise transaction governance or access certification first?

A: Organisations should keep access certification, but prioritise transaction governance where the business impact is highest. If a system handles postings, approvals, or sensitive master data, proving execution appropriateness matters more than proving static entitlement alone. The right order is risk-based, starting with the most consequential workflows.


Background and context

Certified access versus certified transaction

Certified access is a control over entitlement. Certified transaction is a control over execution, meaning the system evaluates whether a specific action is appropriate at the moment it occurs. That distinction matters in ERP because the same identity can hold valid access while a particular posting, approval, or master-data change still violates policy. Transaction certification therefore sits closer to runtime governance than to periodic attestation.

Practical implication: treat access review as a baseline and add transaction controls where business-critical actions need continuous proof of appropriateness.

Governance in motion across ERP and critical apps

Governance in motion means controls follow the actor through the workflow instead of stopping at provisioning or certification. In multi-ERP estates, policy must account for role changes, delegated approvals, and cross-application actions that can create compliance gaps even when each system looks individually configured. The challenge is not only enforcement but evidence, because auditors need a traceable record of why an execution was allowed.

Practical implication: design control points around the transaction path, not just around account lifecycle events.

Where AI creates compliance blind spots

AI introduces decision speed, pattern variation, and exception handling that can outpace manual oversight. In governance terms, that creates blind spots where traditional review cycles are too slow to explain or challenge what happened. The risk is not merely automation, but the widening gap between what a policy says should happen and what an AI-influenced process actually does.

Practical implication: map which ERP decisions are being assisted or triggered by AI and require evidence at the transaction layer, not after the cycle closes.


NHI Mgmt Group analysis

Certified access is no longer a sufficient governance boundary for ERP. The control problem is shifting from entitlement to execution, because compliance failures often happen in the transaction, not the login. Access tells you who could act; transaction governance tells you whether the action itself was defensible. For practitioners, that means identity architecture must be evaluated against business event flow, not only against account state.

Transaction-level assurance is becoming the missing evidence layer in modern IGA. Traditional certification produces periodic snapshots, but ERP operations generate continuous decisions that may never be visible in an access review. That gap matters in audit, fraud review, and segregation-of-duties enforcement. Teams should treat transaction evidence as a governance requirement, not as a reporting enhancement.

AI does not remove compliance obligations, it changes where the proof must exist. When AI influences approvals, routing, or exception handling, the old assumption that a human review cycle will catch misuse becomes weaker. The governance question is whether the program can show why a specific action was allowed at the moment it occurred. For identity teams, this pushes control design toward runtime assurance.

Certified transaction is a useful named concept for the next stage of identity governance. It captures the move from proving that an actor is entitled to act toward proving that each high-risk business action was acceptable at execution time. That concept is especially relevant in ERP, where authorization alone often does not satisfy compliance intent. Practitioners should use it to separate entitlement management from runtime evidence requirements.

Multi-ERP environments amplify policy drift unless governance is centralised at the decision layer. Different application stacks can preserve local rules while still producing inconsistent outcomes across the business process. The practical problem is not simply configuration sprawl, but inconsistent proof of control. Identity leaders should expect audit pressure to move from role design toward transaction observability.

From our research:

  • Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
  • 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
  • For the broader control model, see Ultimate Guide to NHIs , Key Challenges and Risks for how visibility, privilege, and lifecycle gaps combine.

What this signals

Certified transaction is likely to become a durable governance pattern wherever ERP, AI-assisted workflows, and audit requirements intersect. Identity teams that still rely on access-only evidence will keep finding gaps between policy and proof. The practical shift is toward controls that can explain an individual business action, not just a user’s standing entitlement.

Transaction evidence will increasingly matter more than periodic attestation in programmes that handle financial, procurement, or master-data decisions. The organisations most exposed are the ones with fragmented ERP estates and delegated approval chains. For related identity context, the Ultimate Guide to NHIs remains a useful reference for how entitlement sprawl and poor visibility undermine control confidence.

Multi-system governance needs a common policy layer if compliance is going to keep up with operational speed. Where AI or automation changes who touches the transaction path, the evidence standard must stay consistent. The result is a broader identity governance programme that ties access, execution, and accountability together.


For practitioners

  • Map controls to transaction outcomes Identify the ERP actions that need proof of appropriateness, such as postings, approvals, master-data changes, and sensitive overrides. Use those workflows to decide where runtime validation is required beyond standard access certification.
  • Separate entitlement review from execution evidence Keep access recertification for who may operate, but add transaction evidence for what was actually done, when, and under which policy condition. This creates an audit trail that can survive exceptions and delegated activity.
  • Review AI-influenced workflows for control gaps Trace where AI is assisting approvals, routing, or exception handling in business-critical applications and identify the point where human sign-off no longer reflects the real decision path.
  • Standardise governance across multi-ERP estates Define one policy model for transaction approval, exception handling, and evidence capture so that separate ERP platforms do not create different compliance standards for the same business action.

Key takeaways

  • The core issue is not only who can act, but whether each business-critical action can be proven appropriate at the moment it happens.
  • The evidence gap is structural in multi-ERP environments because periodic access certification cannot fully explain execution-time exceptions or AI-influenced decisions.
  • Identity teams should move toward transaction-level assurance where the business risk is highest, while keeping access review as the supporting control.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-4Transaction governance depends on managing access and authorization conditions.
NIST Zero Trust (SP 800-207)PR.AC-5Zero trust requires continuous authorization, not just initial login approval.
NIST CSF 2.0DE.CM-8Transaction evidence strengthens monitoring and detection in compliance-heavy workflows.

Instrument ERP decisions so transaction logs support investigation, audit, and exception handling.


Key terms

  • Certified Transaction: A certified transaction is a business action that has been evaluated for appropriateness at the moment of execution, not just for whether the actor had standing access. In identity governance, it shifts control from entitlement review to runtime proof, which is especially relevant in ERP and other compliance-heavy systems.
  • Governance In Motion: Governance in motion is the practice of applying policy, validation, and evidence during the actual workflow rather than only at provisioning or periodic review. It matters when actions cross multiple systems, because static access controls cannot fully explain dynamic business decisions.
  • Transaction Evidence: Transaction evidence is the record showing what action occurred, why it was allowed, and which policy conditions were met at the time. It is more than a log entry. It is the audit-friendly proof layer that helps identity teams defend exceptions, delegated approvals, and automated decisions.

Deepen your knowledge

Transaction governance and evidence-led identity control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is moving beyond access certification into runtime assurance, it is worth exploring.

This post draws on content published by Pathlock: From Certified Access to Certified Transaction: How Pathlock Nexus Changes the Game. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-06-03.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org