Who should be accountable for using approved identity procurement routes?

Why This Matters for Security Teams

Approved identity procurement routes are not just a purchasing detail. They determine which vendors can issue or manage credentials, what contract terms govern those services, and who can approve exceptions when an identity source is needed quickly. When that ownership is unclear, organisations often end up with shadow renewals, mismatched pricing, and uncontrolled scope creep across service accounts, API keys, and certificate lifecycles. That turns procurement into an identity risk boundary.

NHI Management Group has repeatedly shown how often identity control breaks down in the real world. The Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That is why contract visibility, renewal authority, and vendor scope all matter to security governance, not only to procurement. NIST also treats procurement-linked control ownership as part of a defensible control environment in NIST SP 800-53 Rev. 5 Security and Privacy Controls.

In practice, many security teams encounter approved-route failures only after a vendor has already been renewed, expanded, or repurposed without current IAM oversight.

How It Works in Practice

Accountability should be shared, but it cannot be shared loosely. Procurement typically owns vendor selection, commercial terms, and contract records. IAM leadership owns the identity requirements that make the vendor acceptable, such as supported authentication methods, secret handling, rotation, logging, and offboarding. Programme sponsors own the business need and confirm that the route still matches the use case. One named owner must keep the approved route catalogue current so that renewal, exception, and escalation decisions do not drift over time.

That owner should maintain a simple control record for each approved route: vendor name, allowed identity types, contract expiry, data handling constraints, support for secrets rotation, and the escalation path for urgent exceptions. In environments with service accounts, API keys, or certificate-based access, the approved route should also map to lifecycle obligations, because the route is only safe if the organisation can revoke and rotate access reliably. The Top 10 NHI Issues research is useful here because it highlights how often governance gaps appear when NHI ownership is fragmented.

A practical operating model usually includes:

• a single contract or vendor register tied to the IAM governance process
• pre-approved procurement paths for common identity services
• mandatory security review before any exception or renewal
• evidence of offboarding, rotation, and access removal obligations in the contract
• periodic recertification by procurement, IAM, and the business owner

This is consistent with NIST guidance on establishing accountable control ownership and with the emerging view that identity procurement is part of security governance, not a standalone buying exercise. These controls tend to break down when a vendor is inherited through acquisition or programme change because no one updates the approved-route register.

Common Variations and Edge Cases

Tighter contract control often increases administrative overhead, requiring organisations to balance faster delivery against stronger visibility and renewal discipline. That tradeoff becomes sharper when multiple business units buy the same identity service or when regional procurement rules differ. Best practice is evolving here, and there is no universal standard for whether procurement or IAM should be the formal system owner, but the operational answer is clear: the security-relevant owner must be identifiable and current.

Edge cases usually involve exceptions. Emergency procurement for incident response may bypass normal approval flow, but it should still land in the same register and be reviewed after the event. Mergers, shadow IT, and outsourced operations can also weaken the model because the approved route may no longer match the actual identity supplier. In those situations, contract visibility matters as much as technical control, since expired or broadened agreements can silently create unmanaged access paths.

The governance lesson is simple: if the institution cannot state who owns the approved route today, it cannot prove the route is still approved. That is why current guidance points to shared accountability with one named operational owner, rather than diffuse ownership across committees or tool teams. The 52 NHI Breaches Analysis reinforces how often visibility gaps and weak lifecycle controls show up after the fact, not before.

Related resources from NHI Mgmt Group

• Who is accountable when AI pentesting is run outside approved scope?
• Who is accountable when segmentation fails because of identity abuse?
• Who should be accountable for non-human identities in healthcare identity programmes?
• Who is accountable when identity governance is still based on manual exceptions and delayed reviews?