How should organisations secure identity when business teams buy technology outside IT?

Why Decentralised Buying Creates Identity Gaps

When business teams buy technology outside IT, the security problem is usually not the purchase itself but the way identity decisions fragment across teams. Each department may choose a different login method, different approval flow, and different level of assurance for users, contractors, and external partners. That creates uneven trust, weak onboarding standards, and blind spots in offboarding, auditability, and fraud detection. For a subject like this, the core question is whether identity is governed as a shared control plane or left as a local feature of each tool. NIST’s control families are useful here because they separate access governance, authentication strength, and monitoring into distinct responsibilities, as reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, many security teams encounter the identity failure only after a business unit has already approved a tool with its own exceptions and workarounds.

How Identity Should Be Governed Before Tools Are Adopted

The practical answer is to make identity requirements a pre-adoption gate, not a post-purchase cleanup task. Security and identity teams should define the minimum acceptable assurance for sign-in, account recovery, privileged access, role assignment, and deprovisioning before a department is allowed to onboard a new platform. That does not mean every tool must be configured identically. It means each tool must fit within an approved pattern for how users are verified, how access is granted, and how exceptions are handled.

In most environments, the most effective model is to separate policy from procurement. Procurement can still move quickly, but it should only be able to contract with products that can support centrally defined identity requirements. Common controls include single sign-on, enforced multi-factor authentication, lifecycle linkage to authoritative identity sources, and logging that lets security teams trace who accessed what and when. Where a product cannot support those controls, the organisation should decide whether to compensate with compensating controls, accept a formally owned exception, or reject the tool entirely.

A useful way to think about this is that decentralised buying is only manageable when the identity layer stays central. If each team can create its own authentication rules, external sharing model, or admin hierarchy, then the organisation inherits many small trust systems instead of one governable standard. That increases the chance of inconsistent access reviews, orphaned accounts, and overly broad privileges. It also makes incident response slower because security teams have to reconstruct access logic from multiple vendors and business owners rather than from a shared design.

• Define a minimum identity baseline that every new tool must meet before purchase approval.
• Require business owners to map users, admins, and external collaborators to a central identity process.
• Make exception approval time-bound and reviewable, not informal.
• Check that offboarding and access review responsibilities are explicit before go-live.

Where this breaks down most often is in low-friction SaaS adoption, because the product looks harmless until the organisation tries to govern it at scale.

Where Decentralised Procurement Changes the Control Model

Tighter identity governance often increases friction for business teams, so organisations have to balance speed against assurance rather than pretending both are free. The real trade-off is between local convenience and enterprise visibility. If the policy is too rigid, teams will route around it; if it is too loose, the organisation loses control over account creation, recovery, and privileged access.

There are also some edge cases that need different treatment. A low-risk collaboration tool used by a small internal team may not need the same approval depth as a platform holding customer data or supporting regulated workflows. Similarly, if a business team buys a tool that is truly standalone and never touches corporate accounts, the identity risk may be lower, but the residual governance question is still who owns the user lifecycle and how misuse is detected. Industry guidance is not fully unanimous on whether every exception should be centralised in the same workflow, but there is broad agreement that the assurance threshold should rise with data sensitivity, administrative power, and external exposure.

The main operational mistake is to treat vendor login convenience as a substitute for identity governance. A fast rollout can still be secure, but only if the organisation decides in advance which identity shortcuts are acceptable and which ones are not. That becomes especially important when business teams can approve tools that grant broad admin rights, external sharing, or unmanaged self-registration.

Organisations that manage this well usually build a repeatable decision path: what the tool does, what identities it will trust, what access it needs, and who can revoke it. When those questions are answered centrally, decentralised buying becomes a controlled intake process rather than an identity sprawl problem.

Risk and Threat Considerations

The main risk is identity sprawl created by inconsistent buying, because fragmented approval paths can leave the organisation with weak authentication, unmanaged accounts, and unclear ownership of access decisions. The threat is not limited to external attack; internal misuse, over-permissioning, and poor offboarding also become more likely when departments adopt tools with their own identity rules.

Failure mechanism: A business team signs up for a platform outside the standard approval path, accepts the default login and admin model, and creates accounts or integrations that never pass through central lifecycle controls. That can leave orphaned access, excessive privilege, weak recovery processes, and poor logging that blocks effective review or investigation.

Impact: The organisation can lose visibility into who has access, how access was granted, and whether access was revoked on time. That increases the chance of account misuse, audit failure, data exposure, and slow containment when a tool or identity is compromised.

Practitioner Guidance

What to prioritise: Set a clear identity baseline for any tool that can create users, accept corporate logins, or expose sensitive data. The first decision is not technical integration; it is whether the platform can operate inside a centrally governed identity model.

Decision rule: If the tool cannot support the organisation’s required sign-in, access review, and offboarding process, treat that as a governance blocker rather than a convenience issue. If the business case is strong enough to justify an exception, make the exception explicit, time-bound, and owned by a named business sponsor.

What practitioners underestimate: The hardest part is usually not initial sign-on but lifecycle control after adoption. Many tools look manageable at purchase time and become risky later because no one owns role changes, dormant accounts, or admin revocation.

Practitioner takeaway: Secure identity by making business-led buying enter a controlled approval pattern, not by trying to clean up each tool after it is already embedded in the business.

Related resources from NHI Mgmt Group

• How should organisations govern SaaS access when teams can buy apps outside central IT?
• How should security teams measure the business value of identity security?
• How should IAM teams show that identity work supports business goals?
• How should security teams handle identity decisions when business context changes quickly?