Genuity alternatives expose the limits of ITSM-style access control

At a glance

What this is: This is an analysis of Genuity alternatives that shows ITSM-style access control improves workflow efficiency but still leaves identity governance gaps around SSO, integrations, and auditability.

Why it matters: It matters because IAM and IGA teams should not confuse ticket handling with governed access decisions, especially when app requests, approvals, and review trails need to support NHI, autonomous, and human identity programmes.

Context

ITSM-style access control is a workflow layer, not an identity governance model. It can route requests, capture approvals, and expose status updates, but those functions do not by themselves guarantee that access is tied to a governed lifecycle, a clear entitlement model, or a reliable review trail.

The article's core point is that Genuity alternatives are being judged on access handling as much as on ticketing. The governance gap appears when organisations assume a service desk process can substitute for SSO, integration depth, and audit-ready control over who gets access, for how long, and under whose authority.

Key questions

Q: What breaks when ITSM tools handle tickets but not access governance?

A: The process breaks at the point where a service request turns into an entitlement decision. Ticket systems can log, route, and report, but they often do not preserve the policy context needed to approve access, scope it correctly, or revoke it later. That creates drift between request intent and actual access granted.

Q: Why do missing SSO and integrations matter for access governance?

A: Because access governance depends on connected identity signals. If users authenticate outside SSO or if approval systems do not integrate with directories and target apps, the organisation cannot reliably confirm who has what access or whether the approved change actually took effect. That weakens assurance and makes audits harder to defend.

Q: How do security teams know whether approved access is still justified?

A: They need to compare the approved entitlement with actual usage, then review access that is unused, excessive or inconsistent with the original business case. If the organisation cannot connect the request to subsequent activity, the approval trail is incomplete and stale access can persist unnoticed.

Q: What should teams do when a service desk is used for app access requests?

A: Use the service desk for request intake and communication, but require the identity system to enforce approval, provisioning, review, and removal. That keeps the operational workflow useful without letting it become the control itself. The goal is a request process that feeds identity governance rather than replacing it.

Technical breakdown

Why ITSM approvals are not identity governance

ITSM systems are designed to manage service work, while IAM and IGA are designed to manage identities, entitlements, and accountability. When an access request is handled as a ticket, the workflow may record who approved it, but that does not necessarily establish least privilege, entitlement lifecycle ownership, or certification-grade evidence. The control exists only as a process step unless it is linked to identity source-of-truth data and downstream revocation logic. In practice, that is where many access programs become operationally efficient but governance-light.

Practical implication: separate request routing from entitlement governance, and require the access process to produce identity-grade evidence.

Where SSO and integrations change the control boundary

The article's drawback section points to missing SSO and limited integrations, which matters because access control breaks down when the control plane cannot connect to the systems where entitlements are actually enforced. Without SSO, the user experience becomes fragmented and account sprawl grows. Without integrations, approvals and updates remain isolated from the application layer, so the organisation cannot reliably prove that an approved request became an actual, bounded permission. This is a control boundary problem, not just a usability issue.

Practical implication: verify that approval workflows are integrated with identity providers and target applications before treating them as access controls.

Auditability depends on lifecycle evidence, not ticket history

A ticket log can show a request happened, but auditability requires more than chronology. Practitioners need evidence of who requested access, who approved it, what entitlement changed, when it was granted, and how it will be reviewed or removed. The article's emphasis on changelogs, approval timestamps, and reporting points toward the right direction, but those artefacts only become governance evidence if they map to lifecycle events and review obligations. Otherwise, the organisation is left with operational traceability but weak access assurance.

Practical implication: bind approval records to entitlement changes, review dates, and offboarding triggers so audit evidence survives beyond the ticket.

NHI Mgmt Group analysis

ITSM-style access control is not a substitute for governed identity lifecycle. A request queue can accelerate approvals, but it does not by itself define ownership, entitlement duration, or revocation responsibility. That means the access model may look orderly while still allowing governance drift, especially when teams treat a help desk as the access authority. Practitioners should treat ticketing as evidence capture, not as the control itself.

The real weakness in this category is the separation between workflow and enforcement. If SSO, application integrations, and audit trails are incomplete, the approval path and the actual permission state diverge. That divergence creates a false sense of control because the organisation can see the request but not necessarily the full identity state that follows it. The implication is that access governance must be measured at the identity layer, not just the service desk layer.

Workflow efficiency only matters when it preserves entitlement accountability. Faster approvals and cleaner status updates are useful, but they are not the objective. In identity programmes, the harder question is whether every access decision can be tied to a named entitlement, a valid business owner, and a reviewable lifecycle event. Teams that cannot answer that question are operating an ITSM process, not an access governance process.

Access reviews lose value when the process is ticket-centred instead of entitlement-centred. Review campaigns need stable evidence of what access exists, who owns it, and when it should expire. A service workflow that lacks those anchors can produce activity without assurance. The practical conclusion is simple: governance for human, NHI, and autonomous access alike has to start from the entitlement state, not from the ticket history.

From our research library:

• Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
• Read next: NHI Lifecycle Management Guide

What this signals

ITSM workflows can improve speed, but they do not close the identity gap on their own. The programme risk is assuming that a polished request-and-approval path equals access governance. In practice, teams still need a system of record for entitlements, revocation, and certification, or the workflow becomes a front end for weak control.

Access governance gets stronger when the approval path and the identity state are linked. That linkage is what turns a ticket into evidence. Without it, organisations may have process transparency without being able to prove who has access, why they have it, or when it should disappear.

For practitioners

• Separate service tickets from entitlement decisions Define the service desk as a request and evidence layer, then make the identity platform the system of record for grants, expirations, and revocation.
• Require SSO coverage for access workflows Treat missing SSO as a control gap when users must create separate accounts or re-authenticate outside the identity provider for access requests and approvals.
• Bind approvals to lifecycle events Record who approved access, what entitlement changed, the expiry condition, and the review date so the audit trail reflects the actual access lifecycle.
• Validate integration depth before adopting ITSM access controls Check that request, approval, provisioning, and revocation all connect to target applications and directory services, not just to a ticket record.

Key takeaways

• ITSM-style access control can improve request handling without delivering full identity governance.
• The main gap is the disconnect between approvals, real entitlement state, and audit evidence.
• Practitioners should anchor access decisions in identity records, not in ticket histories.

Key terms

• ITSM-style Access Control: A workflow-driven approach that routes access requests, approvals, and status updates through a service management system. It can improve process visibility, but it does not automatically establish identity governance unless it is tied to entitlement enforcement, review, and revocation in the identity layer.
• Entitlement: An entitlement is the permission set that defines what a non-human identity can do after it authenticates. It is usually expressed through roles, policies or access assignments, and unmanaged entitlements are a common reason machine identities become over-privileged over time.
• Auditability: Auditability is the ability to reconstruct who or what acted, what permissions were used, and what data or tools were touched. For AI and NHI governance, it is the minimum evidence needed to investigate incidents, validate controls, and prove that autonomous actions stayed within approved scope.
• Lifecycle Evidence: The operational proof that identity events such as provision, review, rotation, and revocation actually happened. For NHIs and AI-linked credentials, lifecycle evidence matters because a control cannot be trusted if the system cannot show who changed what, when, and why.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.