Live from Fort Lauderdale: ITEXPO and MSP Expo kick off with a focus on
What "Identity as Infrastructure" Actually Means
The phrase reframes identity from a feature bolted onto applications into a layer that everything else depends on, the same way networking and storage are treated as base infrastructure. When identity is infrastructure, questions like "who is this user," "what service is calling this API," and "should this device be trusted right now" are answered by a shared system rather than reimplemented inside each app. That shift matters because most breaches are ultimately identity problems: a credential is reused, a token is over-scoped, or a machine account has standing access nobody remembers granting.
Treating identity this way pushes teams to standardize on a small number of authorities for authentication and authorization, then make every workload speak to them. Human logins, service-to-service calls, and automated agents all resolve back to the same policy engine, so access decisions become consistent and auditable instead of scattered across codebases.
Why This Lands at an MSP-Focused Event
For managed service providers, identity is the product surface that touches every client at once. An MSP manages accounts, devices, and access across many customer environments, so a weakness in how identity is provisioned or revoked multiplies quickly. Framing identity as infrastructure gives providers a way to offer consistent controls—onboarding, offboarding, privilege changes—as a repeatable service rather than a per-client scramble.
It also changes the sales conversation. Instead of selling a single tool, an MSP can position identity as the foundation that ties monitoring, patching, and access management together. That is a durable relationship: clients rarely rip out the system that governs who can log into everything.
Practical Moves for Teams Adopting the Model
You do not need a full replatform to start treating identity as infrastructure. The useful early work is inventory and consolidation: know every place an account or key can be created, then reduce how many of those places exist. From there, the goal is making access temporary and reviewable by default.
- Inventory every source of identity—user directories, service accounts, API keys, and machine credentials—and map who can create them.
- Prefer short-lived, automatically rotated credentials over long-lived secrets that linger in config files.
- Tie access to policy rather than to individual grants, so revoking a role removes access everywhere at once.
- Log every authentication and authorization decision to a central place you can actually query during an incident.
- Treat offboarding as an automated event, not a manual checklist someone might forget.
The Tradeoffs Worth Naming
Centralizing identity concentrates both control and risk. A shared authority is easier to govern, but it also becomes a high-value target and a single point of failure if it goes down—so availability and recovery planning for that layer become non-negotiable. Teams should plan for the identity system's own outages the way they plan for a database or network failure, including break-glass access that is tightly logged.
The other honest cost is migration friction. Applications that manage their own logins will resist being pulled into a shared model, and some legacy systems simply cannot delegate authentication cleanly. The realistic path is incremental: bring new workloads onto the shared layer from day one, wrap the systems you can, and accept that a few holdouts will need compensating controls for a while. Progress here is measured less by a launch date than by how much of your access is governed centrally versus handled by hand.