Identity-centric architecture
In short: In identity-centric architecture, access depends on who or what is asking and the context of the request, not on network location. A central identity provider authenticates users, devices and workloads, a policy engine decides access, and short-lived tokens carry the result to applications.
Identity as the new perimeter
When staff work from anywhere, applications run in several clouds and partners connect over the internet, a network perimeter no longer marks who is trusted. Attackers increasingly steal credentials or session tokens rather than break firewalls. Identity-centric architecture responds by making identity the main control point: every access decision starts with a strong answer to "who or what is this, and should it be allowed right now?". This is a core idea of zero trust, described in NIST SP 800-207.
Building blocks
- Central identity provider (IdP): one authoritative directory, such as Microsoft Entra ID, Okta or an on-premises directory federated to the cloud.
- Single sign-on (SSO): applications trust the IdP through SAML 2.0 or OpenID Connect (OIDC), so they never handle passwords themselves (see SSO and federation).
- Strong authentication: MFA everywhere, moving towards phishing-resistant methods such as FIDO2 security keys and passkeys (see MFA and passwordless).
- Device identity: managed devices have their own identity and health status that policy can check.
- Workload identity: services and scripts get their own identities with short-lived credentials instead of shared passwords or long-lived keys (see workload identities).
- Lifecycle: joiner, mover and leaver processes, ideally automated from the HR system, so access follows role changes.
Context-aware access
A policy engine, often called conditional access, combines identity with context: device compliance, location, sign-in risk and the sensitivity of the application. It can allow, require step-up authentication, limit the session (for example, view only) or block. The result is a short-lived token, so access is re-evaluated often.
| Aspect | Network-centric | Identity-centric |
|---|---|---|
| Trust based on | IP address or VPN connection | Verified identity plus context |
| Access granted to | Whole network segments | Specific applications |
| Checked | Once at connection | Per session or request |
| Main risk | Lateral movement after one breach | Identity system compromise |
Designing it well
- Consolidate identities into one IdP and remove local accounts where possible.
- Enforce MFA for everyone and phishing-resistant MFA for admins.
- Use role- or attribute-based access control and review permissions regularly.
- Separate admin accounts and use just-in-time privileged access (see PAM).
- Treat the IdP as tier-zero: harden it, restrict who can administer it and keep break-glass accounts protected and monitored.
- Send sign-in and audit logs to your SIEM and alert on risky patterns, such as impossible travel or MFA fatigue.
Tip: identity-centric does not mean network controls disappear. Keep segmentation as a second layer; if the IdP is ever compromised, it limits the damage.
Practice
Why has identity become the main control point?
What does conditional access add to authentication?
Why should workloads have their own identities?
Key takeaways
- Identity, not network location, is the main access control.
- A central IdP with SSO means applications never handle passwords.
- Conditional access combines identity with device and risk context.
- Give workloads their own short-lived identities.
- Protect the identity provider as your most critical system.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.