What should teams do when a user has both create and approve access?

Why This Matters for Security Teams

When a user can both create and approve, the organisation has effectively given one identity the power to start, authorise, and often conceal a transaction without meaningful challenge. That breaks segregation of duties, weakens detective controls, and creates an easy path for fraud, abuse, or accidental policy bypass. The same pattern shows up in non-human workflows too, where excessive privilege is common across NHIs and service accounts.

NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a reminder that access design failures are usually structural, not exceptional. For human access, the same principle is reflected in the OWASP Non-Human Identity Top 10, where privilege sprawl and weak governance are recurring themes. Security teams should treat combined create-and-approve access as a control design problem first, and a user exception second.

In practice, many teams discover the conflict only after a questionable approval, not through intentional role engineering or periodic access review.

How It Works in Practice

The practical response is to separate duties wherever the business process allows it. A user who initiates a request should not be the same identity that approves it, posts it, or reconciles it. This is true whether the workflow is a procurement system, a payments platform, a CI/CD pipeline, or an AI-assisted operations console. The control objective is not just compliance, but making it materially harder for one person to complete and hide an action alone.

Start by classifying the access into three buckets: truly conflicting, conditionally acceptable, or operationally unavoidable. If the conflict is real, split the role and move approval authority to a different person, queue, or policy tier. If the conflict is legitimate, require a documented exception, a named business owner, a time limit, and a review date. NIST’s SP 800-53 Rev. 5 Security and Privacy Controls supports least privilege and separation of duties as core control expectations, even when implementation details vary by environment.

• Remove combined access from standard roles before granting it to individuals.
• Use temporary elevation or JIT approval rights only when the workflow cannot be redesigned.
• Log the requester, approver, timestamps, and business justification for every exception.
• Monitor for self-approval, rapid back-to-back approvals, and unusual approval volume.

For identity-heavy environments, the same design logic applies to NHIs: use the 52 NHI Breaches Analysis to understand how privilege concentration and weak oversight turn routine access into breach conditions. These controls tend to break down in small teams and legacy systems where one person owns the full workflow because no alternate approver or compensating control exists.

Common Variations and Edge Cases

Tighter separation of duties often increases operational overhead, so organisations have to balance fraud resistance against process speed. Best practice is evolving around exception-based models rather than blanket denial, especially in smaller environments where strict dual control is not always practical.

One common edge case is emergency access. A user may need create and approve permissions during incident response, after-hours support, or low-volume operations. In those cases, the safer pattern is time-bound elevation with post-event review rather than permanent combined access. Another edge case is automation: if an agent or service account can both create and approve, that is not a harmless shortcut, it is a high-risk workflow that should be treated as a privileged NHI pattern and reviewed under the same governance lens described in the Ultimate Guide to NHIs — Key Challenges and Risks.

There is no universal standard for every workflow yet, but current guidance suggests preserving independent approval wherever the action has financial, security, or compliance impact. If dual-role access cannot be removed, the exception should be narrow, logged, monitored, and periodically revalidated. That is especially important in systems where approvals are easy to script, queue, or replay without human scrutiny.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?
• When does JIT access create more risk than it reduces?