IT security solutions are becoming identity control problems

At a glance

What this is: This is a vendor analysis of IT security solution categories that argues the deciding issue is not the tools themselves, but whether identity visibility, access control, and compliance are governed together.

Why it matters: It matters because IAM, NHI, and broader identity programmes increasingly have to govern security tools as access-bearing systems, not just as point products with separate administration.

Context

IT security solutions are often treated as product categories, but the governance problem is identity control: who or what can access, change, or inherit privilege across those tools. When security platforms sit outside a unified identity model, organisations end up with fragmented entitlement decisions, weak auditability, and poor visibility into who can actually do what.

Zluri's article frames six categories of security tooling, from SaaS security to cloud security, and the common thread is that each one introduces access, configuration, and compliance decisions that must be governed. For IAM and security teams, the practical issue is not which tool category exists, but whether the associated identities, permissions, and logs are managed as part of one control plane.

Key questions

Q: How should security teams govern access across sysadmin tool sprawl?

A: They should treat SaaS, endpoint, ITAM, ITSM, backup, and documentation tools as one identity control surface, not separate operational systems. The practical goal is to connect ownership, approval, review, and revocation so access can be traced from request to removal. A single inventory is not enough without lifecycle enforcement.

Q: Why do security platforms create identity risk even when they are meant to reduce risk?

A: Because each platform introduces additional humans, service accounts, tokens, and delegated permissions that can outgrow their original purpose. The risk rises when those rights are scattered across products, because auditability breaks down and revocation becomes inconsistent. A security control that cannot be governed as an identity surface eventually becomes another unmanaged privilege domain.

Q: What breaks when SaaS change management is separated from IAM processes?

A: When SaaS change management is separated from IAM, teams lose visibility into who should still have access after a change, which accounts or integrations are obsolete, and whether approvals match current state. That separation typically produces orphaned access and incomplete audit trails. A unified process is needed to keep operational change and identity governance aligned.

Q: How do you know if a security tool has too much privilege?

A: Look for broad remediation rights, shared admin accounts, opaque integrations, and logs that record actions but not accountable identities. If the platform can change multiple systems faster than access can be reviewed, the privilege footprint is too large. The test is whether every high-risk action can be tied back to a named, governed identity.

Technical breakdown

Why security tools become identity control surfaces

Security tools do not operate in isolation once they are connected to SaaS apps, endpoints, clouds, and data systems. Each integration creates a new identity control surface: administrators, service accounts, API-based connectors, and delegated permissions all expand the number of actors that can affect security outcomes. The governance challenge is that these tools often look like operational controls, yet they behave like privileged access points with their own entitlement lifecycle. When visibility, compliance checks, and audit logs are split across products, the organisation no longer has a single view of who can perform high-risk actions.

Practical implication: treat every security platform as an access-bearing system and include it in identity inventory, entitlement review, and privileged access governance.

How SaaS, network, endpoint, and cloud controls inherit entitlement risk

The article's category breakdown shows the same pattern across SaaS security, network security, endpoint security, data security, and cloud security. Each category depends on permissions that can be over-scoped, misconfigured, or left unreviewed. In SaaS, that can mean app-level access and delegated sharing. In network and cloud tooling, it can mean configuration rights that change the environment itself. In endpoint and data controls, the issue becomes whether administrators and connected systems can enforce policy without creating standing privilege that outlives its purpose.

Practical implication: map the entitlement model for each security tool category separately, then enforce least privilege and periodic recertification across all of them.

Identity governance is the control layer beneath security tooling

Identity governance is the discipline that makes security tooling auditable. Without it, the organisation can collect signals, deploy controls, and generate reports while still failing to answer the basic question of who is authorised to use or administer each system. That is why visibility and compliance appear so often in the article's argument. They are not auxiliary benefits. They are the conditions that determine whether security tools reduce risk or merely redistribute it into another unmanaged administrative plane.

Practical implication: align security tool onboarding, review, and offboarding with identity governance workflows rather than leaving each platform to manage its own access model.

Threat narrative

Attacker objective: The objective is to exploit fragmented governance around security tools so that access remains excessive, unaudited, or difficult to revoke.

1. Entry occurs when a security tool is adopted without a unified identity inventory, leaving administrators, connectors, and delegated accounts outside central governance.
2. Privilege escalation follows when tool-specific admin rights or API-connected access are granted broadly enough to configure, monitor, or remediate multiple security domains.
3. Impact emerges when those unmanaged permissions allow misconfiguration, weak auditability, or delayed revocation across SaaS, network, endpoint, data, or cloud controls.

Breaches seen in the wild

• CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Security tooling is now an identity governance problem, not just a control selection problem: The article's real signal is that security categories only work when the identities behind them are governed as tightly as the systems they protect. Visibility, compliance, and access control are the common failure points because every tool becomes another privileged access surface. Practitioners should treat security platforms as part of the identity plane, not outside it.

Entitlement sprawl inside security products creates hidden privilege concentration: SaaS admins, network automation accounts, endpoint managers, and cloud security operators often accumulate rights faster than teams can review them. That produces a control gap where the organisation believes it has layered security, but each layer is itself broadly empowered. The field should stop assuming that a security product is safe simply because its purpose is security.

Identity control must extend to the administration of controls themselves: The article describes a category view of IT security, but the governance lesson is cross-category. If the people and systems operating those controls are not inventory-managed, recertified, and offboarded, then the control stack inherits the same unmanaged access risk it is supposed to reduce. The implication is a tighter convergence between IAM, PAM, and security operations.

Identity blast radius is the right concept for this problem: A security tool's risk is not limited to its own UI or dashboard. Once it has delegated access into SaaS, cloud, endpoint, or data systems, its blast radius is determined by the scope of the identity behind it. Security leaders should measure the privilege footprint of each control platform as part of programme governance, because that footprint now defines containment.

What this signals

Security control stacks now need identity governance at the point of administration: As organisations add SaaS, endpoint, cloud, and data controls, the governance burden shifts to the identities operating those tools. The practical implication is that IAM and PAM teams need a shared view of administrative reach, not separate oversight after deployment.

Identity control must extend beyond user access into tool ownership: The more security functions are delegated to platforms, the more important it becomes to govern who owns, approves, and retires the identities behind those platforms. Without that layer, control sprawl becomes privilege sprawl.

Security outcomes depend on whether audit logs can be tied to accountable identities: Logs alone do not create governance. Teams need clear ownership, enforceable access boundaries, and offboarding discipline so that a tool's administrative power remains attributable and revocable.

For practitioners

• Inventory every security platform as an identity-bearing system Record human admins, service accounts, API tokens, and delegated connectors for SaaS, network, endpoint, data, and cloud tools in the same identity inventory.
• Recertify administrator and connector permissions Review who can configure, remediate, or export data from each security tool, and remove broad standing rights that are no longer needed.
• Tie security tool onboarding to governance workflows Require approval, ownership, and offboarding steps for every new control platform so access is governed from day one instead of after deployment.
• Measure the privilege footprint of control platforms Assess whether each product expands operational reach beyond its stated purpose, especially where automation or cross-system remediation is enabled.
• Unify audit logs across control categories Correlate admin actions, configuration changes, and access events from SaaS, network, endpoint, data, and cloud security products into one reviewable trail.

Key takeaways

• Security platforms are not just controls, they are identity-bearing systems that need governance over administrators, connectors, and delegated access.
• The article's central insight is that visibility and compliance fail when access to the tools themselves is not managed as part of the identity plane.
• Practitioners should inventory, recertify, and offboard the identities behind security tools with the same discipline used for other privileged access.

Key terms

• Identity Control Surface: Any system or workflow that materially influences who can access what. Ticketing platforms become part of this surface when they approve, route, or fulfil access changes, which means they must be governed like identity infrastructure, not just operational software.
• Privilege Footprint: The total extent of authority a platform or identity has across systems, data, and operational workflows. For security tools, this measures how far configuration, remediation, and export rights can reach beyond the product itself.
• Administrative Reachability: Administrative reachability is the ability to connect to and interact with a system’s management surface. If that reachability is public or broadly shared, the organisation has expanded the attack surface around privileged operations and made exposure much easier to exploit.
• Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.