Who should own lifecycle control when the application vendor does not support identity standards?

Why This Matters for Security Teams

When an application vendor does not support identity standards, the enterprise still owns the risk, the audit trail, and the offboarding outcome. Vendor limitations do not remove the need to govern who can act, when access expires, and how revocation is proven. This is why lifecycle control remains a security and IAM responsibility, not a procurement footnote. The patterns documented in the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 show that weak lifecycle ownership is where many identity failures begin.

The practical risk is simple: if the app cannot automate provisioning or revocation, teams often fall back to shared accounts, manual tickets, and delayed deprovisioning. That creates blind spots in access reviews, weakens zero trust assumptions, and makes exception handling indistinguishable from control failure. NHI Management Group’s NHI Lifecycle Management Guide treats lifecycle ownership as an enterprise control plane issue, because the business impact lands on the enterprise even when the vendor platform is behind. In practice, many security teams discover the gap only after a failed offboarding or a stale account is already being used.

How It Works in Practice

Ownership should sit with the enterprise control owners, usually IAM, security architecture, and the application owner, with clear escalation to the business system owner when the vendor cannot support standards. The vendor may define technical constraints, but it should not define the control model. Current guidance suggests documenting compensating controls in a formal exception record, then binding those controls to review dates, evidence collection, and named approvers.

That usually means three things. First, define the authoritative source of identity and the authoritative source of access decisions, even if the application only accepts local credentials or manual updates. Second, enforce just-in-time administrative access where possible, with short-lived credentials, break-glass procedures, and rapid revocation workflows. Third, map every manual step to an owner and a measurable checkpoint so that offboarding is not dependent on tribal knowledge.

For teams looking to mature this process, the most useful reference points are the lifecycle processes for managing NHIs and the Guide to the Secret Sprawl Challenge, which both emphasize that manual handling must be treated as a temporary exception, not a steady state. Where identity standards are absent, control evidence becomes as important as control design. These controls tend to break down in heavily customised legacy applications because manual admin paths, undocumented service accounts, and opaque database permissions make revocation incomplete and hard to prove.

Common Variations and Edge Cases

Tighter lifecycle control often increases operational overhead, requiring organisations to balance security assurance against business continuity and vendor constraints. That tradeoff is real, especially when the application is business-critical and the vendor roadmap for standards support is unclear.

There is no universal standard for this yet, but the safest pattern is to treat vendor non-support as a risk factor, not as a waiver of enterprise accountability. Some teams use compensating controls such as quarterly recertification, dual approval for privileged changes, and service account inventories, while others require network segmentation and limited blast radius until the vendor matures. The Guide to NHI Rotation Challenges is useful here because rotation failures often reveal where ownership was never truly assigned.

If the app cannot support automated revocation, best practice is evolving toward short-lived access wrappers, proxy-based enforcement, or a controlled retirement plan for the application itself. A vendor may be the source of the technical limitation, but the enterprise must still own the exception, the compensating control, and the evidence trail. That alignment is what makes the control defensible during audit, incident response, and offboarding review.

Related resources from NHI Mgmt Group

• Who should own vendor risk management in an identity programme?
• What do identity teams get wrong when they treat SOC and SOX as the same control problem?
• Who should own remediation when SOX control exceptions are found?
• How should security teams implement Triple-A identity access management standards?