A zero trust architecture is a way to design security so that a company protects each app, API, and data store directly, instead of trusting anyone who sits inside its network. Every request to a resource is checked on its own. Where the user is connecting from does not earn them access.
NIST SP 800-207 is the standard that describes this design. This course uses it to protect one running company: 4,000 employees and contractors who reach web apps, APIs, and admin consoles from home, from the office LAN, and from the internet. One question shapes the design. When 1,200 of those people work remotely every day, what does a network location prove about them?
The baseline is the common VPN design. A user signs in once, the VPN places them on the internal network, and from there the user can reach apps and databases. The network edge acts as the only gate.
That design has one weakness. Once a stolen password or an infected laptop gets through the VPN, every reachable system treats it as a trusted insider. NIST calls this implicit trust, and zero trust removes it. Let’s take a look at where this trust sits in the baseline path:
The diagram shows a single check at the VPN, with the internal network, app, and database all sitting behind it. Nothing after that point asks who is calling or from what device. A compromised contractor laptop gets the same reach as a verified employee.
NIST SP 800-207 lists seven tenets. Three of them act as hard constraints on every design choice in this course.
Each tenet becomes a control with a visible outcome. Here is how the tenets map to controls in our company:
The mapping shows that no tenet is a product. Each one is a requirement that a component must satisfy and that an auditor can test.
The functional scope is fixed. The design protects web apps, APIs, and admin access for employees and contractors, whether they connect from the internet or the office LAN. Office LAN users get no exemption.
Two non-functional signals follow from 4,000 users. Every access decision adds latency to each session, so the decision path must stay fast. The decision service also becomes a single point of failure, so it must stay available. Here is how perimeter-first access compares with zero trust style access against those needs: