How should security teams decide which IAM systems must stay under direct control?

How to decide which IAM systems stay under direct control

Direct control is justified where IAM failure would become a business outage, a regulatory breach, or a loss of cryptographic custody. The test is not whether a platform is important in the abstract, but whether the organisation can safely tolerate someone else operating it during a crisis, audit, jurisdictional challenge, or key recovery event.

That makes the decision architectural, not organisational preference. If the system protects revenue-producing, customer-facing, or regulated operations, or if it governs keys and credentials that cannot be delegated without changing the risk profile, security teams should treat it as part of the control plane.

What belongs in the direct-control zone

The strongest candidates are systems that can independently shut down access, break emergency recovery, or change who can administer the estate. That usually includes the primary identity provider, privileged access tooling, directory and federation components, and any IAM layer that controls production credentials, recovery accounts, or signing authority. The more a platform defines access to other systems, the more it deserves hands-on control.

Jurisdiction matters because IAM often stores personal data, audit evidence, and authentication material across borders. If a provider cannot meet data residency, sovereignty, lawful access, or change-control expectations in the locations that matter to the business, shared-service convenience stops being a good trade-off. Direct control is also more defensible where segregated environments or regulated subsidiaries require different policy sets.

Key custody is the other hard boundary. Once an IAM platform issues, stores, or protects long-lived secrets, certificates, tokens, or recovery material, the question becomes who can actually revoke, rotate, or reconstruct trust under pressure. If the answer depends on a third party’s operational schedule or opaque support process, the organisation no longer fully owns the control plane.

How to separate must-control systems from shared services

A practical decision rule is to ask what happens if the IAM platform is unavailable, altered incorrectly, or placed under external operational control for 24 to 72 hours. If the answer is “we can continue safely with compensating procedures,” the platform may be a shared service. If the answer is “we would lose access, breach obligations, or be unable to recover,” it belongs under direct control.

That assessment should be based on outage impact, recovery time objectives, and whether a manual fallback exists that is actually usable. A system may look central but still be suitable for managed outsourcing if it is non-critical, has low blast radius, and can be restored from independent backups without changing trust relationships. Conversely, a modest-looking directory can be mission-critical if other platforms depend on it for authentication, privileged access, or certificate trust.

For cloud and hybrid estates, teams should be especially careful with delegated administration, federated trust, and identity providers that span tenants or business units. The convenience of centralisation can hide a single point of failure, especially when one policy mistake, one compromised admin path, or one vendor outage affects every downstream application at once.

Risk and Threat Considerations

When IAM is not directly controlled, the main risk is correlated failure: one outage, misconfiguration, or support delay can disconnect users, services, and recovery paths at the same time. That becomes a security problem as soon as the platform also governs administrative access, because an attacker who reaches it can change privileges, disable logging, or lock defenders out of the environment.

Failure mechanism: Externalised IAM introduces dependency on another operator’s change process, support queue, jurisdiction, and incident response speed. If that operator cannot restore access quickly or safely, the business inherits both availability risk and trust risk in the same control point.

Impact: Loss of direct control can translate into revenue interruption, regulatory non-compliance, failed recovery, privilege abuse, or an inability to execute emergency revocation when credentials or signing keys are compromised.

Practitioner Guidance

What to prioritise: Classify each IAM component by blast radius, recovery dependency, and custody requirements before debating vendor preference. The systems that gate production access, privileged administration, or recovery should be reviewed first.

What to verify: Confirm who can restore service, who can rotate credentials, who can revoke federation trust, and whether those actions can be executed without waiting on an external operator. If the answer is unclear, the system is not under real direct control yet.

Decision rule: If a failure would stop regulated operations, block customer access, or prevent safe credential or key recovery, keep the system in-house or under tightly governed operational control. If it is a non-critical support function with low blast radius and a viable fallback, shared operation is easier to justify.

Practitioner takeaway: Direct control is warranted where IAM is part of business continuity and trust custody, not just identity administration. The right question is whether the organisation can still authenticate, recover, and revoke when the platform itself is under stress.

Related resources from NHI Mgmt Group

• How should security teams decide when identity management should be treated as a shared IAM control rather than a standalone programme?
• How do security teams decide whether a control-plane flaw is an IAM problem or an application problem?
• How can security teams tell whether multi-cloud IAM is actually under control?
• How should security teams prioritise NHI remediation in cloud environments?