Does this mean network security is obsolete?

No. Network controls can still reduce risk within a broader resource-focused design.

Is de-perimeterization identical to zero trust?

They are related, but de-perimeterization is a historical concept and zero trust has its own formal architectural guidance.

Must all data move to the cloud?

No. The concept concerns protection and trust boundaries, not a requirement to choose a particular hosting model.

AI Glossary / Data governance and quality / Intermediate

De-perimeterization

Definition

De-perimeterization is the shift away from treating an organization's outer network boundary as the main basis for protecting its information. The term is associated with the Jericho Forum's work on securing collaboration across organizational boundaries. It recognizes that people, devices, applications, and data can operate outside a single controlled network. The aim is to protect resources in those circumstances, not to remove security safeguards indiscriminately.

What it means

An internal network address does not by itself establish that a device, user, or request should be trusted. Equally, a legitimate business interaction may originate outside the office network. De-perimeterization asks designers to account for these realities when choosing protection. It is a historical security concept with connections to later zero trust approaches, but the terms should not be treated as perfectly interchangeable specifications. Neither is a single product that can be installed to finish the work.

How it works

Map important information and the collaborations that use it, including partners, remote workers, and hosted services. Identify the identities, applications, devices, and permissions involved in each interaction. Apply protection at appropriate resource and service boundaries, support secure communications, and maintain evidence about access and use. Revisit assumptions that grant broad trust merely because a connection reaches an internal network. Existing network controls can remain valuable, but they should fit a wider design that addresses the resource and the requested action.

Three practical examples

Partner collaboration: a supplier receives access to a specific project workspace rather than broad trust based on a network connection.
Remote work: access to a confidential application depends on suitable identity and device checks, not simply the user's presence in an office.
AI services: a model-development team assesses the permissions and data flows between its repository, cloud training environment, and external collaborators instead of assuming one perimeter contains the workflow.

Think of it this way

Think of protecting valuable documents through rules for each reading room and authorized reader, even when the rooms are in several buildings. A fence around headquarters remains useful but cannot govern every copy elsewhere. The analogy is limited because digital access can change dynamically, software identities also request resources, and copied information may no longer remain under the original system's control.

Worked example

In an original design exercise, an engineering firm collaborates with four suppliers. Each supplier needs one project repository and no access to the other three. A broad connection into the corporate network would not, by itself, express those four distinct permissions. The team instead defines an access matrix: supplier A to project A, B to B, C to C, and D to D. It then identifies the authentication, authorization, communication protection, and logging needed to enforce that matrix. A person already on the office network receives no automatic permission to all four projects. The exercise illustrates a change in trust assumptions, not a claim that a four-row matrix alone implements a secure architecture.

Illustrative case study

Fictional example: Maple Studio moves a research collaboration to a hosted workspace. Its first design assumes that anyone arriving through the company gateway can see all datasets. After reviewing the collaboration requirements, the team gives project-specific permissions and documents how external researchers are added and removed. It also examines local downloads and service accounts. This invented case shows that changing the hosting location is only one part of redesigning access and information protection.

Common misconceptions and mistakes

Do not interpret de-perimeterization as an instruction to disable firewalls, eliminate segmentation, or make services public. Do not assume every external request is acceptable or every internal request is safe. Encryption alone does not decide whether a user should receive data. Also, avoid claiming that a modern zero trust product automatically reproduces all the historical Jericho principles. A credible design must explain the protection, dependencies, and residual risks of the actual workflow rather than relying on the terminology.

Business use

The concept helps businesses reason about collaboration that crosses offices, suppliers, and hosted environments. It encourages security teams to support necessary work with clear resource permissions and accountable access. For AI projects, it is useful when data preparation, training, evaluation, and deployment occur across different services. Prioritize the most consequential workflows, identify owners for each access decision, and test whether permissions remain appropriate when people, devices, or partnerships change. Migration should preserve usable controls while correcting unsupported trust assumptions.

Check your understanding

A contractor can connect to the internal network. Does that establish permission to download a sensitive training dataset?

Answer: No. Network reachability and authorization to use that dataset are different questions. The applicable identity, purpose, permission, and information-handling rules still need to be enforced.

Related terms

Identity and access management
Least privilege
Segmentation
Data-centric security
zero trust
network perimeter
secure collaboration

Learn next

read the distinction between authentication and authorization, then map one cross-company workflow. Mark every place where information leaves a system you control. For each place, identify the recipient, intended use, access decision, and what protection remains after a permitted copy is made.

Sources

Sources: Microsoft Security Blog, Back to the future: What the Jericho Forum taught us about modern security, https://www.microsoft.com/en-us/security/blog/2020/10/28/back-to-the-future-what-the-jericho-forum-taught-us-about-modern-security/ , article read as Microsoft's professional interpretation; The Open Group, historical standards information, https://www.opengroup.org/view-standards-information-base-historical , relevant excerpt consulted; NIST SP 800-207, https://csrc.nist.gov/pubs/sp/800/207/final , abstract consulted for the related zero trust distinction. Jericho Forum Commandments, Version 1.2, May 2007, https://collaboration.opengroup.org/jericho/commandments_v1.2.pdf , both pages independently consulted during editorial review after an earlier retrieval failure. The historical primary document supports asset-specific protection and continued boundary-firewall use; examples are original.

Previous: De Moivre's law Next: De-skilling