The good old days of the classic network perimeter have completely fallen by the wayside. Users work from home, coffee shops (more often than I care to admit), airports, and client sites. Applications sit in multiple cloud providers. Contractors, service providers, and automated workloads all need access to the same core systems. The one element that still ties access together is, well, identity. If you treat identity as your perimeter, you stop caring about where traffic comes from and start caring about who is asking for access, how they proved it, and what they are allowed to do.
An identity perimeter is a security model where identities and their context, not networks, decide access. Before a request is granted, your controls answer a few basic questions. Who is this user or workload? How strongly have they authenticated? Which application or resource are they trying to reach? Under which conditions is that acceptable? IP addresses and network segments still exist, but they become secondary signals, not the main line of defense. This mindset puts your identity provider, directories, device signals, and authorization policies at the center of your security architecture.
More from Dave Lewis:
Dave Lewis
Dave Lewis
In practical terms, an identity perimeter (and no, it isn’t new) relies on centralized authentication through a primary identity provider, strong multi-factor authentication, broad single-sign-on coverage, conditional access policies, and continuous evaluation throughout the session. If users are still signing in directly to critical SaaS platforms with separate passwords, those applications sit outside your perimeter. If privileged users hold standing admin access without strong factors, the wall around identity is already full of gaps. Swiss cheese is the current perimeter.
Strong authentication is only the beginning of what's required
Strong authentication is the most obvious starting point. Passwords alone cannot carry the risk your business now has. Multi-factor authentication should be enforced for as many identities and applications as possible, with a preference for phishing resistant methods such as FIDO2 security keys or platform authenticators. SMS codes and basic push prompts are better than nothing, but let’s be honest, they remain vulnerable to social engineering and fatigue attacks. At the same time, you cannot ignore usability. If users are flooded with prompts or blocked from doing their jobs, they will seek workarounds. Risk based rules help here. Low risk activity can remain quiet, while sensitive actions or unusual patterns trigger step up authentication.
Every important application should sit behind your identity provider. If a system owns financial data, customer records, production infrastructure, or source code, it should never be reached by bypassing the IdP. When SSO coverage is half-assed and incomplete, you cannot enforce uniform policies, you lose visibility into sign-in patterns, and deprovisioning becomes fragile. This is where you need a security technology that will provide unified access. Treat SSO coverage as a measurable outcome to a point. Start with your highest impact systems, move them behind the IdP, and enforce policy there instead of relying on each individual application to “do security” correctly. Then make use of technology that will shore up where SSO fails.
Authentication proves who you are. Authorization decides what you can do. Identity perimeters gain real strength from careful authorization design. Roles and groups should reflect business functions and privilege boundaries, not individual names or ad-hoc requests. Use least privilege as the default posture. Standard user accounts handle daily work. Separate admin accounts are created specifically for elevated actions. Those admin accounts should often use just-in-time access that is requested, approved, time limited, and logged. Standing global administrator roles are equivalent to leaving the keys inside the lock.
A static, login only view of identity is no longer enough. Tokens get stolen. Devices drift out of compliance while a session is still active. Real attackers do not wait politely for the next login prompt. Continuous access evaluation closes part of that gap. When device posture changes, when risk scores from your IdP spike, when a user tries to perform a sensitive action such as changing payout details or resetting another admin’s MFA, you can demand re authentication or terminate the session entirely. Access becomes a stream that can be cut off at any time, not a one time decision at the door.
Lifecycle and governance processes decide whether your identity perimeter holds over time. If HR or a central directory is not the source of truth for workforce identities, access will drift. New hires gain privileges by ticket and favor rather than structured role assignments. Movers accumulate entitlements from previous roles. Leavers keep access for days or weeks after they depart. A mature design connects HR events to identity creation, group membership, and application provisioning. Role changes adjust access automatically. Terminations trigger revocation across all connected systems within tight time limits. Access reviews for high impact systems provide an extra layer, forcing managers and system owners to confirm that each identity still requires each permission.
Non-human identities sit inside the same perimeter even though they do not “log in” as humans do. Service accounts, workload identities, CI pipelines, and integration users all reach data and control planes. Static long lived secrets for these identities create attractive targets. Wherever possible, favor managed identities, short lived tokens, and automated rotation. Assign clear owners to every non human identity, and include them in reviews. A perimeter that focuses only on people leaves a wide opening for attackers who prefer to compromise automation.
Visibility and measurement show whether the model works. Identity provider logs should flow into your SIEM alongside endpoint and cloud logs. From there you can correlate suspicious patterns, such as unusual sign ins on privileged accounts or repeated MFA failures on sensitive apps. Basic metrics help you track progress. Measure the percentage of active users with enforced MFA. Track how many high value applications are behind single sign on. Count stale accounts that still have access to critical systems. Measure the time from HR termination to full revocation. Put those metrics into the same review cycles where you already discuss patch levels, incident counts, or vulnerability backlogs.
Avoid these patterns
Several recurring patterns weaken an identity perimeter:
- Teams enable MFA, but rely mainly on weak factors and never disable legacy protocols like basic auth for mail.
- Or worse, they only utilize MFA for a subset of the overall system footprint. Shared accounts stay in use because they are convenient, even though they destroy accountability and create password sprawl.
- Senior staff receive broad exceptions that bypass controls, without compensating safeguards.
- Non-human identities remain unmanaged because they are “just integration accounts.”
Each of these patterns quietly reintroduces a softer perimeter inside a model that claims to be identity centric.
Do this instead
If you own or influence IAM, you do not need a multi-year program to move forward. You can act with concrete steps:
- This week, pull a list of your most critical applications and mark which ones sit behind the IdP.
- In the same exercise, extract a report of all users who hold admin roles in your identity platform, SasS manager, and cloud tenants, and core SaaS tools.
- Enforce strong MFA and create distinct admin accounts for everyone with elevated privileges.
- Over the quarter, design a simple conditional access policy set for those high impact apps based on MFA strength and device posture, and run an access review on one critical system where you actually remove unjustified access. There will be plenty of opportunities.
Identity is already the attackers' path of least resistance. That makes it your real perimeter whether you acknowledge it or not.
Treat it as a first-class control surface. Assign owners. Set policies in clear language. Connect it to your lifecycle systems. Feed its logs into your monitoring stack. Then pick a specific date, schedule a working session with your security and IT leads, and decide which applications move behind extended access management and which admin roles lose standing access.
The perimeter will not redesign itself.
Plug the holes.
