The Platform Is the Product, Part II: Identity Is the Control Plane
IAM is one of the few enterprise capabilities that touches nearly every employee, consultant, application, server, cloud resource, and automated workload. When it is designed well, access becomes consistent, auditable, and largely automated. When it is designed poorly, every new application introduces another account, another password, another manual process, and another security boundary.
This article will not attempt to cover every possible IAM product or implementation pattern. Instead, it focuses on the guiding principles that can help an organization establish an identity framework that scales as the business, technology footprint, and cloud platform continue to grow.
Identity is not merely a security service. It is the control plane for the enterprise platform.
One Identity Provider to Rule Them All
I tried hard to work a Lord of the Rings reference into this section, but the principle itself is fairly simple:
There should be one primary enterprise identity provider.
Your identity provider should act as the central control plane for workforce authentication and access. Employees should not have one identity for Microsoft 365, another for the cloud platform, another for source control, and separate local credentials for every application they use.
That model does not scale.
A centralized identity provider gives the organization one place to enforce authentication standards, multifactor authentication, conditional access, account status, group membership, and sign-in policies.
There is an important distinction between an identity provider and the original system of record for a person.
For employees, the authoritative source may be an HR system. For contractors, it may be a vendor-management or procurement process. Those systems establish who the person is and whether they remain affiliated with the organization.
The identity provider takes that information and becomes the enterprise control plane through which the user authenticates and receives access.
There will always be a few deliberate exceptions. Cloud root accounts, emergency access identities, workload identities, and certain customer-facing systems may require different patterns. Those exceptions should be intentional, tightly controlled, and documented.
They should not become an excuse to create a second identity ecosystem.
Every Application Must Participate in the Enterprise Identity Model
Every enterprise application should integrate with the organization’s identity provider whenever technically possible.
For modern web applications, that typically means federation through standards such as OpenID Connect or SAML. Where supported, user provisioning and deprovisioning should also be automated through standards such as SCIM.
The goal is straightforward:
- Users authenticate through their enterprise identity.
- Access is governed centrally.
- Disabled or terminated users lose access automatically.
- Application owners do not maintain separate password policies and account lifecycle processes.
When evaluating a new enterprise product, identity integration should be considered a baseline capability, not a premium feature or future enhancement.
A product that requires every user to maintain a separate local account creates long-term operational and security overhead. In many cases, that should raise questions about the maturity of the product.
Legacy systems will not always cooperate.
Some applications cannot support modern federation. Some operational systems may have contractual, technical, or regulatory constraints that make immediate replacement impractical.
In those cases, the system should still participate in the broader identity strategy through compensating controls. This may include an identity-aware proxy, a centrally managed remote-access platform, privileged access management, network isolation, or tightly governed vaulted credentials.
A password manager is an important safety net for the credentials that inevitably remain.
It should not become the organization’s primary IAM architecture.
If every employee needs hundreds of credentials stored in LastPass, 1Password, or another password vault just to perform their job, the organization does not have centralized identity. It has centralized password storage.
Grant Access Through Roles and Groups, Not Individuals
Directly assigning permissions to individual users may seem convenient in the moment.
Over time, it creates an access model that is almost impossible to understand, review, or maintain.
Access should be granted through groups and roles.
A scalable model separates organizational membership from application permissions:
This structure allows the organization to manage access based on responsibilities rather than individual names.
When someone joins the Accounts Payable team, they receive the appropriate baseline access. When they leave the team, that access is removed. The application owner manages what the role can do, while the business or department owner manages who belongs in the group.
The group structure should generally reflect two things:
- The shape of the organization
- The standard tools, platforms, and responsibilities within that organization
For each enterprise application, begin with a small and understandable set of standard roles.
Avoid creating a unique role for every individual or every possible variation of access. Excessive role customization can become just as difficult to manage as direct assignments.
Direct user permissions should be allowed only by documented exception, with a clear owner and expiration date.
Design for the Entire Identity Lifecycle
IAM is not just an onboarding process.
It must support the full lifecycle of an identity: joining, changing roles, and leaving the organization.
New employees should receive baseline access based on their role and department. Contractors should have a sponsor, a defined purpose, and an expiration date. When someone changes positions, obsolete access should be removed—not simply supplemented with additional permissions.
That last point matters.
Many organizations handle onboarding reasonably well but struggle with internal role changes. Over time, users accumulate access from every position they have held. The result is privilege creep: access that was once justified but is no longer necessary.
A mature identity lifecycle should account for:
- New employee and contractor onboarding
- Role and department changes
- Temporary project access
- Contractor and vendor expiration dates
- Termination and immediate revocation
- Dormant and inactive accounts
- Periodic access reviews
- Privileged access recertification
- Exceptions with owners and expiration dates
Offboarding should be consistent and immediate.
When an employee or contractor leaves the organization, disabling the central identity should revoke access across integrated applications and cloud platforms without requiring administrators to remember every system the person may have used.
This is one of the clearest benefits of treating IAM as a shared platform capability rather than a collection of individual application settings.
Plan for External Users from the Beginning
Most organizations depend on vendors, consultants, implementation partners, auditors, and other external users.
External access should not be treated as an unusual scenario or handled through improvised local accounts.
The identity model should define how external users are sponsored, authenticated, approved, reviewed, and removed.
Every external identity should have:
- A known internal sponsor
- A defined business purpose
- A limited scope of access
- An expiration or review date
- Clear ownership
- Strong authentication requirements
Where practical, external users should authenticate through their own managed identity or through a controlled guest-identity process rather than receiving permanent internal credentials.
External access should also be easy to identify.
Administrators and application owners should be able to clearly distinguish employees from vendors and consultants during access reviews and incident response.
The goal is not to make external collaboration difficult.
The goal is to make it deliberate.
Treat Privileged Access as Temporary
Administrative access deserves a separate model.
Permanent administrator privileges increase risk and make it difficult to distinguish normal work from elevated activity. Where practical, privileged access should be granted only when needed and only for the time required to complete the task.
A mature privileged access model may include:
- Separate administrative identities
- Just-in-time role activation
- Approval for highly sensitive roles
- Stronger authentication requirements
- Time-limited access
- Session and activity logging
- More frequent access reviews
- Emergency access procedures
Administrative access should never be used for routine daily work.
An engineer who needs to review logs, monitor a deployment, or inspect the health of a production system may not need full administrator rights. Read-only and operational roles should be available so users can perform their responsibilities without receiving broad control of the environment.
Privilege should be available when required, not permanently attached to a person.
Every Workload Needs an Identity
IAM is not limited to human users.
Applications, servers, CI/CD pipelines, Kubernetes workloads, integration services, automation tools, and AI agents all need to authenticate and access resources.
Each workload should have its own identity.
Shared credentials make it difficult to determine which system performed an action. They also create a broad security impact when a credential is exposed.
Cloud platforms provide better patterns:
- Managed identities
- Instance or server roles
- Kubernetes workload identities
- Short-lived federated credentials
- CI/CD identity federation
- Service-specific roles
These approaches allow the platform to issue temporary credentials based on the identity of the workload rather than requiring developers to store long-lived secrets.
Service accounts and application identities are not inherently the problem.
Static credentials are.
Wherever practical, avoid storing access keys, client secrets, or passwords in application configuration, source control, CI/CD variables, or manually maintained secret stores.
A secret that never needs to exist cannot be leaked.
As AI agents begin interacting with enterprise systems, workload identity will become even more important. An agent should not act through a shared user account or inherit broad access from the person who created it.
It should have its own identity, narrowly scoped permissions, an accountable owner, and a complete audit trail.
Cloud Access Should Be Role-Based and Environment-Aware
Cloud platform access should integrate directly with the enterprise identity provider.
Users should authenticate through their normal enterprise identity, and security groups should map to cloud IAM roles. Local cloud users should be avoided except for tightly controlled emergency or root-access scenarios.
However, restricting the entire cloud console to a small group of administrators can recreate the same gatekeeper model we are trying to move away from.
The better approach is to make access role-based, environment-aware, and aligned with job responsibilities.
A practical model may look something like this:
Production
Production access should follow least-privilege principles.
Write access should be limited, privileged changes should be tightly controlled, and users should receive only the permissions required to support or operate the services they own.
Nonproduction
Engineering teams may receive broader access in development and test environments, provided that appropriate security boundaries, monitoring, and cost controls remain in place.
Sandbox
Sandbox environments should support experimentation and learning with greater autonomy.
They should also have clear boundaries:
- No production data
- Cost limits and budgets
- Limited connectivity to enterprise systems
- Automated expiration where practical
- Defined ownership
Read-Only Access
Read-only access can often be provided more broadly.
Giving teams visibility into logs, metrics, configurations, and resource health reduces unnecessary operational requests without exposing the environment to unauthorized change.
The principle should be limited privilege, not limited participation.
Every Identity and Entitlement Needs an Owner
IAM becomes difficult to govern when nobody knows who is responsible for a group, role, application account, workload identity, or exception.
Every identity and entitlement should have an accountable business or technical owner.
That owner should be able to answer:
- Why does this access exist?
- Who should receive it?
- What does it permit?
- How often should it be reviewed?
- When should it expire?
- Who approves changes?
Unowned access is unmanaged risk.
This is particularly important for service accounts and workload identities. Human users usually have a manager and an employment status. Application identities may persist for years after the original project team has moved on unless ownership is deliberately maintained.
Design for Failure
Centralizing identity creates consistency and control.
It also creates a critical dependency.
If the identity provider is unavailable, federation is misconfigured, or administrators are accidentally locked out, the organization still needs a safe recovery path.
An IAM strategy should include:
- Emergency or break-glass identities
- Cloud root-account protections
- Secure storage of recovery credentials
- Monitoring and alerting on emergency account use
- Documented recovery procedures
- Periodic testing
Emergency access should be difficult to use accidentally but reliable when it is truly needed.
When one identity platform controls access to the enterprise, its recovery path must be designed as carefully as its normal operating path.
Plan Ahead
The worst time to design an IAM strategy is after hundreds of applications, groups, roles, and service accounts already exist.
Standards should be defined early.
At a minimum, the organization should establish consistent patterns for:
- Application federation
- User and group naming
- Standard application roles
- Privileged access
- External identities
- Workload identities
- Access reviews
- Exception management
- Account ownership
- Offboarding and expiration
Not every access scenario can be predicted in advance.
The objective is not to eliminate every exception. It is to create a stable model so that exceptions remain exceptions rather than becoming the normal way work gets done.
Do not make the identity model up one application at a time.
Identity as a Platform Capability
A strong IAM strategy should make secure access easier, not harder.
Employees should be able to access the tools they need without maintaining dozens of credentials. Engineering teams should be able to use cloud services without waiting for an administrator to manually create every permission. Applications and workloads should authenticate without embedding long-lived secrets. External partners should be able to collaborate without creating unmanaged accounts.
This is what it means to treat identity as part of the platform.
The goal is not to place more gates between the organization and technology.
The goal is to establish consistent guardrails so that more people can build, automate, and innovate safely.
A scalable platform does not remove access controls. It makes the right access predictable, automated, and easy to govern.
Looking Ahead
Identity is only one part of the enterprise platform, but it establishes the foundation for nearly everything that follows.
Security policies, data access, cloud governance, application delivery, automation, and AI all depend on the organization’s ability to establish who—or what—is requesting access and what that identity should be allowed to do.
In the next article, we will continue exploring the governance capabilities required to build a platform that enables innovation without sacrificing security, cost control, or operational discipline.