What do organisations get wrong about managing unmanageable applications?

Why This Matters for Security Teams

“unmanageable applications” are usually unmanaged because they sit outside the normal approval path, not because the business stopped caring about risk. Employees adopt tools that remove friction, and once an app is embedded in a workflow, the security problem shifts from blocking adoption to governing it. That is why treating the issue as a one-time IT exception process so often fails.

The deeper risk is identity and secrets sprawl. NHI Management Group notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 79% have experienced secrets leaks, with 77% causing tangible damage. Those patterns are consistent with what happens when teams rely on policy documents instead of controllable technical guardrails. The right frame is governance, aligned to practical identity controls and lifecycle management, not moralising about shadow IT.

Current guidance from NIST Cybersecurity Framework 2.0 supports that shift by emphasising governance, risk oversight, and continuous protection rather than ad hoc approval alone. In practice, many security teams encounter the real exposure only after a shared credential, weak password, or disabled two-factor authentication has already been used in production.

How It Works in Practice

Managing these applications starts with acknowledging that the enterprise does not fully control adoption, but it can control how access is granted, monitored, and revoked. A workable model uses discovery, classification, and minimum viable governance. Security teams identify the app, determine what data it touches, and decide whether it can be wrapped in approved identity and secrets controls or must be isolated.

The most effective controls are usually simple and repetitive: enforce single-user accounts where possible, prohibit shared credentials, require MFA for any access path that supports it, and place secrets in approved storage rather than inside browsers, spreadsheets, or source code. NHI Mgmt Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and NHI Lifecycle Management Guide both emphasise lifecycle visibility because unmanaged access usually becomes visible only during incident response.

In parallel, teams should align the application to formal governance: who approved it, what business purpose it serves, which data classes it can access, what logging exists, and how offboarding works when the app is no longer needed. That aligns well with the control intent in NIST Cybersecurity Framework 2.0, especially where identity, protective technology, and continuous monitoring intersect.

• Require a named business owner for every unmanaged app.
• Map the app to data sensitivity and authentication requirements.
• Replace shared credentials with per-user or per-workflow access where feasible.
• Set a review cadence for access, secrets, and MFA enforcement.
• Document the exit plan before the app becomes operationally critical.

These controls tend to break down when the app is deeply embedded in a department’s daily operations because users will route around controls if security has not provided an equally workable alternative.

Common Variations and Edge Cases

Tighter application control often increases friction for business teams, requiring organisations to balance speed of adoption against governance and support overhead. That tradeoff becomes sharper when the app has no enterprise admin console, no API for policy enforcement, or limited support for federated identity.

There is no universal standard for this yet, but current guidance suggests a tiered response. Low-risk apps may be approved with basic authentication and limited data exposure. Higher-risk apps should require stronger identity controls, logging, and explicit owner accountability. If an application cannot support those conditions, the safer decision may be to constrain its use rather than pretend it is manageable.

This is also where many organisations mistake exceptions for strategy. A one-off waiver without review dates, secrets rotation, or offboarding steps simply creates a permanent exception with higher risk. NHIMG’s Top 10 NHI Issues shows how often identity-related weaknesses persist once access moves outside standard controls, and the lesson transfers directly here: if security cannot observe it, rotate it, or revoke it, it is not truly governed.

In practice, the hardest cases are not the unknown apps but the ones everyone depends on and nobody can replace quickly.

Related resources from NHI Mgmt Group

• What do security teams get wrong about managing client access in MSP environments?
• What do organisations get wrong about using managed services to close cybersecurity staffing shortages?
• What do organisations get wrong about managing unsanctioned AI use?
• What do organisations get wrong about blocking unsanctioned applications?