Network perimeters still matter, but location alone is not a reliable way to decide whether a user or device should access a particular resource. People work from different locations, applications run in cloud services and systems connect across organisational boundaries. A network boundary can remain one useful control, but it should not be treated as the only control or as proof that everything inside it is trustworthy.
The limits of location-based trust
Traditional perimeter models often separate an internal network from the internet. A connection from inside the boundary may be treated differently from one outside it. That approach can help control network traffic, but it creates a risk when access decisions rely too heavily on a device’s location or assume that everything inside the network is safe.
NIST’s Zero Trust Architecture publication describes zero trust as an approach that moves from static, network-based perimeters toward users, assets and resources. It says an enterprise should not grant implicit trust solely from physical or network location, and that authentication and authorisation should be performed before a session to a resource is established.NIST SP 800-207
This does not mean removing firewalls, network segmentation or other boundary controls. It means those controls work alongside identity, device and application policies rather than carrying the entire access decision.
Treat access as a resource decision
A more useful access question is: who is requesting access, from which device, to which resource, for what purpose and under what policy? The answer may depend on identity, role, device condition, requested application, sensitivity of the data and the organisation’s operating requirements.
These checks should be proportionate. A user may need different privileges for a finance application, an administrative console and a public website. Access to one should not automatically provide access to all. The principle of least privilege gives each identity only the rights needed for its work, and those rights should be reviewed when responsibilities change.
Zero trust is not a product that automatically enforces every part of this model. NIST defines it as a set of concepts and an architecture that requires planning across components, workflows and access policies. Organisations still need to decide what they are protecting, which systems are in scope and how the controls will be operated.NIST SP 800-207
Identity is important, but not enough on its own
Identity provides information about the person, service or device requesting access. Strong authentication can help establish that an identity is genuine, while role and access policies determine what it can do. However, identity controls need to work with endpoint security, network design, application configuration, monitoring and incident response.
A compromised account can still be used by an attacker. A legitimate user can still make an unsafe change. A service identity may have access no one remembers to review. Access policy needs to account for these possibilities through limited privileges, monitored use and a way to respond when behaviour or risk changes.
Apply controls across the environment
Start by listing important applications and data, the identities that can access them, the devices they use and the network paths involved. Identify external users, administrative accounts, service identities and systems that are no longer actively maintained. Check whether the access rules reflect current responsibilities and whether the organisation can see when those rules are used.
Then prioritise changes. This may include strengthening authentication, reducing excessive privileges, segmenting sensitive workloads, reviewing remote access, improving device management or adding application-specific access controls. The order depends on risk, dependencies and the organisation’s capacity to implement changes safely.
Keep existing business workflows in view. If a control blocks a critical user group or system integration, document the exception, decide who accepts the risk and set a review date. Avoid creating permanent exceptions that no one owns.
Measure whether the operating model is improving
A new control is useful only if someone operates it. Define who reviews access, who approves exceptions, who investigates alerts and who changes policies. Make sure support teams know how to diagnose access problems without weakening controls as a shortcut.
Review practical evidence: access reviews completed, inactive identities removed, privileged access scoped, device policies enforced and exceptions reviewed. These measures do not prove that an organisation is secure, but they can show whether the agreed controls are operating as intended.
Keep the network perimeter in perspective
Perimeter security has not disappeared. It has become one part of a broader design that must account for cloud services, mobile users, third parties, identities and individual resources. The task is to avoid treating network position as a substitute for authentication, authorisation and monitoring.
Read how ZTNA differs from VPN access and why identity is central to modern access. For AltTab’s current assessment, secure access and segmentation scope, see cybersecurity services.