Why do institutions still bypass consortium agreements for identity projects?

They usually bypass them because awareness is fragmented, not because the agreement lacks value. Procurement may not know the contract exists, IT may not know the pricing terms, and leadership may not trust the selection history. That combination creates rework, delays, and avoidable spend in IAM and IGA programmes.

Why This Matters for Security Teams

Identity projects often bypass consortium agreements because the visible problem is procurement friction, while the real problem is governance fragmentation. That creates duplicate evaluations, inconsistent contract terms, and slower adoption of controls that should be standardised across institutions. For identity programmes, especially IAM and IGA, the delay is not just administrative. It can postpone access review, lifecycle enforcement, and secrets hygiene.

Current guidance in NIST Cybersecurity Framework 2.0 treats governance and supply-chain decision-making as core security work, not optional paperwork. NHIMG research shows how quickly identity risk accumulates when governance is weak: in the Ultimate Guide to NHIs, only 5.7% of organisations reported full visibility into service accounts, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. When institutions ignore shared agreements, they often recreate the same blind spots in a new procurement cycle.

In practice, many security teams encounter the cost of bypassed consortium agreements only after the second or third identity platform review has already burned schedule and budget.

How It Works in Practice

Consortium agreements are most useful when institutions need a repeatable path for vendor selection, pricing, legal review, and baseline control expectations. In identity projects, that matters because the implementation is rarely only about software licensing. It also touches authentication policy, privileged access, audit logging, secrets handling, and integration with HR, cloud, and PAM systems. If one institution ignores the agreement, the whole programme can drift into bespoke requirements and one-off exceptions.

Security teams usually see better outcomes when the consortium agreement is treated as a default routing mechanism, not a constraint to be negotiated away. That means procurement checks the agreement first, IT aligns technical requirements to the agreed scope, and leadership verifies that the contract history and due diligence remain acceptable. For identity projects, this can shorten time to deployment while preserving consistent baseline controls.

• Use the consortium agreement to pre-negotiate identity-specific controls such as logging, rotation, and offboarding expectations.
• Map the selected product to NIST CSF 2.0 governance and access-management outcomes before re-opening commercial terms.
• Validate whether the agreement covers service accounts, API keys, and other NHI assets, not just human user access.
• Use published NHI lessons from 52 NHI Breaches Analysis to pressure-test whether the procurement path is reducing or increasing exposure.

This is especially important because NHIMG data shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 71% do not rotate NHIs within recommended time frames. A bypassed agreement may look faster, but it can also undermine the very controls the project is supposed to improve. These controls tend to break down when each institution insists on a unique legal, technical, or data-residency exception set because the shared procurement baseline no longer functions as a true baseline.

Common Variations and Edge Cases

Tighter consortium adherence often increases perceived procurement overhead, requiring institutions to balance speed against standardisation. That tradeoff is real, especially where regulatory constraints, data residency, or legacy integration requirements differ across member organisations.

There is no universal standard for when a consortium agreement should be mandatory for every identity project, but current guidance suggests the strongest case is when the programme affects shared controls, shared funding, or repeatable identity patterns. If a project is narrowly scoped and legally distinct, bypassing may be justified. The risk is that exceptions become the norm.

Some edge cases deserve separate treatment: emergency remediation, sovereign procurement rules, or a consortium agreement that is outdated and no longer maps to modern identity architectures. In those situations, the right response is usually to update the agreement or document a formal exception, not to ignore the agreement quietly. The Top 10 NHI Issues material is useful here because it shows how governance gaps and operational shortcuts often show up together. In short, institutions bypass consortium agreements when the governance path feels slower than the delivery path, but that choice often transfers cost into later remediation and audit friction.

Related resources from NHI Mgmt Group

• How can teams tell whether their identity controls are still gate-based?
• Why do MFA and strong login controls still leave healthcare identity risk?
• How should higher education institutions decide whether workflows are enough for identity governance?
• Who is accountable when identity governance is still based on manual exceptions and delayed reviews?