Why Identity Is Becoming the New Security Perimeter
oktober 08, 2026 • Vaishnavi Khosla
Enterprise security has been centered on a mental model for many years now – a safe corporate network inside, an unsafe internet outside, and a firewall between those two. Being connected to the corporate network meant being trusted by default, whereas not being in the network required earning trust through a virtual private network connection or some kind of a gateway.
This mental model has become obsolete for the majority of enterprises, and that has nothing to do with a specific security breach or technology. Rather, this is the result of a gradual process which involves changes in the way enterprises work – cloud-based infrastructure which operates beyond any perimeter, employees working via their own home networks and devices, third-party partners that have access to the company’s internal infrastructure, and software-as-a-service apps storing sensitive information in the infrastructure the company has no control over.
In place of the network perimeter lies identity. Security teams no longer have to ask whether the request is coming from within the network perimeter. Rather, they now need to ask themselves whether “this particular person or this particular system is allowed to do this particular action in this particular situation.” This question needs to be answered right all the time, regardless of whether the request is coming from anywhere within or outside the organization’s premises.
The Perimeter Didn’t Disappear, It Moved
And it makes sense to be specific about what actually has changed. Companies still maintain their networks, firewalls, and segmentation – all of which is important. What has changed is that network location no longer serves as a reliable trust indicator. With a set of stolen credentials, an attacker does not need to bypass any of the traditional network barriers to move around cloud-based services, SaaS applications, and internal corporate assets. Once they establish themselves as a legitimate user, they are given the trust that such an identity provides.
This is exactly why attacks based on credential theft and misuse still belong to one of the leading reasons behind the vast majority of breaches as described in annual industry-specific breach reports. Hackers have shifted to wherever the real value lies. Since it’s the identity of a user that opens access to all the valuable data and applications, it becomes the target of the attack regardless of its exact nature.
The zero trust architecture, as embodied in guidance such as the CISA Zero Trust Maturity Model, and as promoted by methods such as Google’s BeyondCorp, is basically a reaction to the truth of this situation. The question that it poses is not where you are logging in from. The questions it poses are: Who are you? What are you attempting to do? Is your request in accordance with how you normally behave? And should your access rights be verified before they are granted?
What This Means in Practice
Considering identity the true perimeter alters what security teams must consider a priority, and in reality, there are a few key areas where this becomes apparent.
First of all, there needs to be strong and continuous authentication rather than a gate mechanism. It is clear that single-factor and static password authentication is no longer enough in today’s environment. Multi-factor authentication, risk-based authentication based on context like device posture or geographic anomalies, and continuous session evaluation are becoming standard features.
The second thing that must be considered is granularity and currency of authorization. There is no question that role-based access control was a significant improvement compared to permission-based approach, yet static roles that are set once and then never reconsidered tend to gather unnecessary access rights over time. Workers switch to different departments or projects, contractors finish their job, yet access to resources remains untouched. In this way, there is a large number of standing privileges that are not being used, yet can easily be used by attackers.
Non-human identities deserve the same scrutiny as human identities. Service accounts, API keys, and machine-to-machine identities frequently have sweeping and persistent permissions, and they tend to be far less conspicuous than human user identities. They are also usually not subject to the same onboarding, approval, and offboarding as humans, and thus are an all-too-common source of vulnerability. Any proper identity security policy must apply governance rules not only to human identities but also the non-human identities connecting via other means.
Visibility comes first as well as control. You cannot govern what you cannot see. It is essential to know who the identities are, what access permissions they have, how they were granted, and whether they are actually being exercised.
The Hard Part Isn’t the Technology
Identity and access management tooling has matured considerably. Modern IAM platforms support fine-grained policies, adaptive authentication, automated provisioning and deprovisioning, and detailed audit trails. The technology to implement identity-centric security largely exists and is increasingly accessible even to mid-sized organizations.
The bigger challenge is one of organization. Identity governance cuts across all teams, applications, and processes, and that is why it needs continuous ownership and not just a one-off project. When access reviews are done as a mere compliance check rather than a proper risk review, it is no surprise that the result you get is just that – nothing more than rubber stamping in order to fulfill an audit requirement and reduce no risk whatsoever. It takes ownership of the accounts and entitlements, a scalable process, and real buy-in by the management to consider identity a security issue and not just an administrative one.
Vooruitkijken
With continued adoption of cloud computing, distributed teams, and automation that works independently, the move toward using identity as the key element for security will become stronger. Those organizations that will be the first to embrace change will be the ones that ask not from where the request is being made but rather if it is proper to trust the identity requesting to perform the action.
There will be no going back to the network perimeter; now we are talking about the identity perimeter, and taking it seriously as we did the network perimeter before is something that organizations cannot afford anymore.
Vaishnavi Khosla
Vaishnavi Khosla is a Software Developer II at Bank of America, with hands-on experience in enterprise identity and access management, access governance, and provisioning systems.