The premise, without the slogan.
The older model lets a connection inherit trust because it came from inside an office network or through a familiar device. NIST describes zero trust differently: no user or asset receives implicit trust solely from network location or ownership. Access is decided for a resource using the context relevant to that request.
That does not mean asking people to log in every few seconds or replacing every system at once. It means designing a policy that identifies the resource, checks the requester and device where appropriate, grants only needed access, and produces evidence that the decision worked. The details depend on the environment and the risk of the work.
The useful question is not “Which zero-trust platform should we buy?” It is “Which access assumption could hurt us most, and how will we change and test it?”
A practical starting sequence
Four moves before another purchase.
- 01
Name the resources
Begin with the applications, data, and workflows whose access matters most. Include cloud services, remote entry, administrator accounts, and vendors. If no one owns a resource, that is an important finding—not a reason to guess at its policy.
- 02
Map the access path
Record who or what requests access, from which devices, through which identity and network controls, and for what job. Separate a person's access from a service account's access. Identify where a trusted network location is doing the work that a resource-specific decision should do.
- 03
Choose a bounded first change
Protect one meaningful resource before changing everything. Define the allowed users and devices, an exception path, an approval owner, and a way back if the new policy interrupts legitimate work. Reuse controls you already own where they fit the decision.
- 04
Test and revisit
Check both allowed and denied paths, account removal, vendor expiry, logging, and the response to a lost or compromised device. Record what happened, what remains open, and who will review the policy as the business changes.
What to ask for
The plan should be inspectable.
Ask any provider for a resource-and-access map, the first policy in scope, the owner of its exceptions, the test for permitted and rejected access, and the rollback trigger. Ask which controls already exist and which changes would be a separate project. A diagram without decision owners and validation is not an operating plan.
For regulated work, map the applicable rules and data boundary separately. Zero-trust architecture can support a security program; it is not a certification, a legal opinion, a guarantee against breach, or automatic proof of HIPAA compliance.
Primary sources
Read the architecture, not a product pitch.
- NIST SP 800-207 — Zero Trust Architecture ↗
- CISA — Zero Trust Maturity Model v2 ↗
- CISA — MFA guidance for small and medium businesses ↗
CISA's maturity model is written for federal agencies. It is a useful reference for organizing a conversation, not a mandatory checklist or certification for every small business.