How should IAM teams handle applications that cannot be automated?

By NHI Mgmt Group Editorial Team Updated October 10, 2026 Domain: Governance, Ownership & Risk

Treat them as governed exceptions, not temporary edge cases. Assign named owners, define manual approval and evidence steps, and review access changes on a schedule that matches the business risk of the application. The goal is to make manual execution controlled and auditable, even when standards-based integration is impossible.

When an application cannot be automated, what changes for IAM?

What changes is the operating model, not the accountability. If an application cannot integrate with standard provisioning, deprovisioning, or access review workflows, IAM teams should treat it as a controlled manual process with explicit ownership, evidence, and review cadence. That prevents “exception” from becoming “unmanaged,” which is where access drift usually starts.

The practical difference is that manual handling must be designed, not improvised. The application still needs an access lifecycle, even if it runs through tickets, spreadsheets, approvers, or a legacy admin console instead of an identity platform. The lifecycle processes for managing NHIs page is useful here because the same governance logic applies to any account or access path that cannot be fully automated.

That means the exception should be explicit enough that auditors and operators can answer three questions quickly: who owns it, how changes are approved, and how often access is revalidated. If those answers are vague, the problem is no longer technical limitation, it is governance failure. The Identity Security Programme Guide is a good model for making ownership and RACI responsibilities visible when control execution has to be shared across teams.

How should the exception process be structured?

Start by defining the application as a named exception with a documented reason, scope, owner, and expiry or review date. Do not let “cannot automate” become a standing waiver with no end state. If the application supports sensitive data, privileged functions, or production changes, the manual process should be tighter than for low-risk tools, not looser simply because the workflow is harder.

Manual access changes should follow a repeatable sequence: request, approval, implementation, evidence capture, and post-change validation. The evidence should be specific to the application, such as screenshots, change tickets, logs, or sign-off records that prove who made the change and when. For broader identity programmes, IAM and Identity Provider Buyer's Guide is relevant because it reinforces the distinction between platform automation and the controls you still need when integration is incomplete.

Review cadence should follow risk, not convenience. High-impact applications need more frequent recertification and tighter approval paths than low-impact ones, even if both are handled manually. The goal is not to make the process fast, it is to make it traceable and bounded so that manual execution does not quietly create standing privilege.

What good looks like when automation is impossible

Good practice is a controlled exception register with measurable coverage. Every non-automated application should have an accountable owner, a documented fallback process, and a review schedule that is actually followed. If the process depends on a few people “knowing how it works,” that is a resilience issue as much as an IAM issue.

It also helps to align the manual process with the same concepts used in privileged and lifecycle governance. For example, access that cannot be provisioned or removed automatically should still be time-bounded where possible, reviewed after business changes, and revoked immediately when the business justification ends. The Top 10 NHI Issues page is a useful reminder that overprivilege, stale access, and weak ownership are recurring failure modes whenever lifecycle discipline is weak.

In practice, the strongest signal is not whether the application is automated, it is whether the manual process produces the same governance outcomes: clear accountability, timely removal of access, and proof that approvals were real. If those outcomes are not measurable, the exception is too loose to be trusted.

Risk and Threat Considerations

Unautomated applications tend to accumulate access risk because manual steps are easier to forget, harder to monitor, and more likely to be handled inconsistently across teams. Over time, that creates stale accounts, delayed removals, excessive privilege, and weaker evidence for audits or incident response.

Failure mechanism: Manual access administration breaks the normal lifecycle controls, so removals, reviews, and approvals become dependent on individual follow-through rather than system enforcement. That increases the chance of orphaned access, undocumented changes, and privilege left in place after the business need has ended.

Impact: The application becomes a durable control gap. Attackers and insiders gain a softer target where access may persist longer than intended, review evidence may be thin, and containment is slower if the account is abused or misused.

Standards & Framework Alignment

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

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Manual access paths still need controlled credential and access lifecycle management.
	AC-2 — Account Management	Exception applications still require owned accounts, approvals, and periodic review.
Recommendation — Define manual credential issuance, rotation, and revocation steps for each exception. Assign accountable owners and recertify access for every non-automated application.
ISO/IEC 27001:2022	A.5.15 — Access control	Exception handling must preserve controlled, authorised access decisions.
	A.5.16 — Identity management	Non-automated applications still need governed identities and ownership.
Recommendation — Document the approval and review rules for manual access changes. Maintain an inventory of exception-handled accounts and their owners.
CIS Controls v8	CIS-5 — Account Management	CIS account management directly fits manual exceptions that need ownership and review.
Recommendation — Keep a current exception register and remove access when business need ends.

Practitioner Guidance

What to prioritise: Assign a single business owner and a single IAM owner for every non-automated application, then tie the exception to a review date. If nobody can be named as responsible for approval, removal, and evidence, the exception is not operationally controlled.

What to verify: Check that manual steps are documented in the same detail as automated ones, including who approves, who executes, and what proof is retained. If the process cannot be replayed from the evidence record, it is not audit-ready.

What good looks like: The application has a visible exception status, access changes are completed through a repeatable ticketed workflow, and review cycles shorten as risk increases. Manual does not have to mean weak, but it does have to mean deliberate.

Practitioner takeaway: Treat inability to automate as a governance design problem, not a reason to relax standards, because the control objective is controlled access lifecycle management, not tool-specific elegance.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org