What breaks when a large part of the application estate stays manual?

Why This Matters for Security Teams

When a significant slice of the estate stays manual, identity governance becomes uneven by design. Central IAM can enforce rules for modern apps, but the unmanaged tail still depends on app owners, ticket queues, spreadsheets, and human memory. That creates a split-control model where some access paths are audited and repeatable while others are slow, exception-driven, and hard to prove. For teams trying to demonstrate least privilege, timely removal, and recertification discipline, that split is operationally expensive and audit-sensitive. NHI Management Group notes in the Ultimate Guide to NHIs that only 5.7% of organisations have full visibility into their service accounts, which is a useful proxy for how often the tail is hidden from control owners. The issue is not merely slower processes. It is that manual handling turns routine lifecycle tasks into exceptions that are easy to miss and difficult to evidence against NIST Cybersecurity Framework 2.0 expectations for governance and access control. In practice, many security teams encounter lingering access only after an internal review or incident has already exposed the gap, rather than through intentional monitoring of the unmanaged estate.

How It Works in Practice

The failure mode usually appears in the joins between systems. A modern identity platform may handle joiner-mover-leaver events for SaaS, directories, and cloud resources, but legacy applications, plant systems, and custom admin consoles still rely on manual approval and manual revocation. Those processes create three predictable problems: inconsistent timing, inconsistent evidence, and inconsistent ownership. If a recertification campaign depends on app owners responding to emails, the control is only as strong as the least responsive owner. If deprovisioning depends on a helpdesk ticket, the removal window stretches, and the audit trail becomes fragmented.

Practically, teams usually need to layer controls rather than assume a single IAM workflow will cover everything:

• Classify manual applications as a separate control population, not as a minor exception.
• Define explicit ownership for lifecycle actions, including deprovisioning and access reviews.
• Use compensating controls such as shorter access durations, forced reapproval, and logging of all privileged actions.
• Track evidence centrally so manual approvals still produce reviewable records.
• Prioritise the most sensitive systems first, especially those holding secrets or privileged accounts.

This is where the broader NHI problem becomes visible. The same unmanaged tail that slows access governance also tends to hide service accounts and static credentials. The Ultimate Guide to NHIs highlights that 96% of organisations store secrets outside secrets managers in vulnerable locations, which means manual administration often coincides with weak credential hygiene. Current guidance suggests that identity and access data should be reconciled across directories, ticketing systems, and application records, then validated against policy in a repeatable cadence aligned to NIST Cybersecurity Framework 2.0 governance outcomes. These controls tend to break down when app ownership is diffuse and the manual systems have no reliable event feed because there is no clean trigger for revocation or certification closure.

Common Variations and Edge Cases

Tighter control over the manual tail often increases operational overhead, requiring organisations to balance assurance against support burden. That tradeoff is most visible in environments with outsourced operations, inherited systems, or heavily customised applications where automation is not immediately feasible. In those cases, best practice is evolving rather than settled: some organisations move to semi-automated workflows with human approval gates, while others impose compensating controls such as shorter review cycles and restricted privilege scopes. There is no universal standard for how much manual processing is acceptable, but the risk decision should be explicit, not accidental.

Edge cases also matter. A manual application may be low volume but still high impact if it controls production, payment, or emergency access. Conversely, a large user population does not automatically mean higher risk if the access model is tightly constrained and well logged. The important distinction is whether the manual process can produce timely, complete, and testable evidence. If it cannot, the control objective is only partially met. For teams mapping their exposure, the Ultimate Guide to NHIs is useful for understanding how unmanaged service accounts and stored secrets compound the same governance gap. The practical limit appears when manual ownership spans multiple teams and no one can prove who approved, who revoked, and when the action was completed.

FRAMEWORK_REFS--- [ { "framework_code": "NIST-CSF", "control_ref": "PR.AC-4", "relevance_note": "Manual estate gaps weaken least-privilege enforcement and access review consistency.", "framework_summary": "Map manual apps to PR.AC-4 and enforce compensating access controls plus documented review evidence." }, { "framework_code": "OWASP-NHI", "control_ref": "NHI-03", "relevance_note": "Manual systems often keep secrets and access paths live far too long.", "framework_summary": "Inventory manual-app credentials and shorten renewal, rotation, and offboarding cycles under NHI-03." }, { "framework_code": "NIST-AIRMF", "control_ref": null, "relevance_note": "Manual governance gaps undermine trustworthy operational oversight decisions.", "framework_summary": "Use AI RMF governance practices to assign ownership, evidence, and monitoring for unmanaged systems." } ]

Related resources from NHI Mgmt Group

• What breaks when passwordless is rolled out to only part of an application estate?
• Why do collaboration tools create such a large secrets risk?
• Why do application testing tools matter for NHI governance?
• What makes GenAI usage part of the same secrets problem?