An unmanaged application is a business system used by the organisation but not integrated into the identity team’s standard controls, such as SAML, OpenID Connect, or central lifecycle management. These systems often hide credentials, sessions, and actions from normal IAM visibility, making them high-risk for delegated automation.
Expanded Definition
An unmanaged application is a business system that operates outside standard identity governance, so it is not enrolled in central SSO, lifecycle automation, logging, or periodic access review. In NHI security, that usually means the application can still issue credentials, maintain sessions, or execute automation without the visibility controls expected for a managed workload. Definitions vary across vendors, but the practical distinction is simple: if identity teams cannot provision, attest, rotate, and revoke access through normal controls, the application is unmanaged.
This matters because unmanaged applications often become shadow trust zones where API keys, service accounts, and delegated automations persist long after their business purpose changes. That puts them at odds with NIST Cybersecurity Framework 2.0 expectations for asset awareness, access control, and continuous monitoring. NHI Management Group has repeatedly shown that hidden identity paths are a recurring failure pattern in enterprise environments, especially where lifecycle ownership is unclear, as discussed in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. The most common misapplication is calling an application “managed” simply because it is documented somewhere, when in reality its credentials and access paths remain outside enforcement.
Examples and Use Cases
Implementing control over unmanaged applications often introduces operational friction, requiring organisations to balance tighter governance against the convenience of local app ownership and ad hoc automation.
- A finance portal uses locally stored API keys for nightly exports, but the keys are not rotated through the identity stack, so the system remains outside standard revocation workflows.
- A legacy internal application authenticates users through a homegrown login screen instead of SAML or OpenID Connect, making session oversight and offboarding inconsistent.
- A marketing platform is connected to several SaaS integrations by individual teams, yet no central owner can attest which service accounts still need access or which secrets are active.
- A robotic process automation workflow calls an HR system using a shared credential embedded in a config file, creating an identity path that security cannot see in normal IAM reports.
These patterns align with the risk themes highlighted in Top 10 NHI Issues and with broader machine identity guidance such as SPIFFE, which assumes service identities should be explicit and verifiable. When a platform is truly managed, its enrollment into lifecycle and trust controls should be visible in the same way a federated workload would be. For implementation context, NIST Cybersecurity Framework 2.0 is useful for mapping ownership, monitoring, and remediation responsibilities across the application estate.
Why It Matters in NHI Security
Unmanaged applications are dangerous because they create identity blind spots where secrets, sessions, and delegated actions can persist without policy enforcement. In NHI operations, that is especially severe because a single unmanaged system can hold many more machine credentials than a human account, and NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts. That visibility gap makes unmanaged applications a common entry point for privilege escalation, lateral movement, and silent persistence, especially when credentials are hardcoded, shared, or left unrotated.
This is also a governance issue, not just a technical one. The application may still be delivering business value while simultaneously bypassing lifecycle controls, audit evidence, and ownership review. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks explains why hidden service identities are so often tied to breach conditions. Organisations also need to account for audit and regulatory expectations, as discussed in Ultimate Guide to NHIs — Regulatory and Audit Perspectives. Unmanaged application risk becomes operationally unavoidable only after an incident exposes an unrevoked credential, at which point the application’s identity footprint finally has to be inventoried and brought under control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Unmanaged apps often hide machine identities outside normal governance and visibility controls. |
| NIST CSF 2.0 | PR.AA-01 | Identity and access accountability depends on knowing which applications are managed vs. hidden. |
| NIST Zero Trust (SP 800-207) | GV-2 | Zero Trust requires explicit trust decisions that unmanaged applications usually bypass. |
| NIST SP 800-63 | AAL2 | Applications using weak or local auth instead of federation often fail expected assurance levels. |
| CSA MAESTRO | IAM-1 | Agentic and automated systems need explicit identity governance for every application they touch. |
Replace ad hoc authentication with federated assurance and enforce revocation through centralized identity controls.
