Cybersecurity
Updated
Zero trust is not a product, a network replacement, or a one-time project. For a small business, it is an operating model for making access decisions: identify the resource, verify the user and device to the degree the risk requires, grant only the access needed, observe what happens, and revisit exceptions. The practical path is incremental. Start with the business's most consequential resources and improve the evidence behind each access decision.
NIST defines zero trust around protecting resources rather than trusting a user or asset solely because of network location or ownership. Authentication and authorization apply before a session to a resource is established, and policy decisions use available context. Read NIST SP 800-207 as the architectural foundation, not as a shopping list. A small company can adopt its principles without reproducing a federal enterprise architecture.
Translate zero trust into five operating questions
- What are we protecting? Name the application, data, service, administrator function, device-management system, or workflow.
- Who or what needs access? Identify workforce roles, administrators, service accounts, vendors, applications, devices, and temporary users.
- What conditions should permit access? Consider role, authentication, device state, location or network context, sensitivity, session risk, and the requested action.
- What is the minimum useful access? Limit resource scope, privilege, duration, and administrative standing access without making the work unusable.
- How will we know the policy worked? Define logging, review ownership, exception tracking, user support, and a rollback path.
Zero trust does not mean that every session receives the same control or that one authentication method is universally sufficient. Policy should follow risk, usability, technical capability, regulatory needs, and tested recovery behavior. NIST's CSF 2.0 small-business resources explicitly frame cybersecurity as risk management for organizations with modest plans, making them a useful governance companion.
Phase 0: Establish ownership and a baseline
Do not begin by turning on restrictive policies across the company. Inventory the highest-value business resources and the identities, devices, integrations, and vendors that reach them. For each resource, record a business owner, technical owner, data sensitivity, critical workflows, current access groups, privileged roles, service accounts, authentication path, device expectations, logs, and recovery dependency.
Use observation to find the real environment before enforcing a new model. NIST's 2025 implementation guide describes a phased approach and highlights discovery as a way to validate documented baselines and formulate policy. See NIST SP 1800-35 and its concise zero trust journey takeaways. The examples demonstrate possibilities; they do not endorse a particular vendor or promise the same result in every small-business environment.
Phase 1: Stabilize identity and privileged access
Start with unique accounts, an accurate joiner-mover-leaver process, separate administrator access, removal of stale privileges, and stronger authentication selected for each risk and workflow. Define who approves privileged access, how long it lasts, and how emergency administration works when normal dependencies fail. Review service accounts and application credentials rather than limiting the effort to employees.
For Microsoft environments, Microsoft's Entra role guidance recommends least privilege, just-in-time approaches where supported, limited Global Administrator assignments, and emergency access planning. Treat this as product-specific implementation guidance. Validate licensing, compatibility, administrative capacity, and the recovery path before enforcement.
Phase 2: Add device and resource conditions
Define which resources require a managed device, supported operating system, encryption, endpoint protection, screen lock, or other verified state. Separate a device inventory fact from a device-health signal that the access system can actually consume. Decide how personally owned devices, contractors, kiosks, shared workstations, and mobile access will work. If the business cannot reliably measure a condition, do not claim it is enforced.
Apply the policy first to a controlled group and a narrow resource. Test normal work, remote work, new-device enrollment, lost-device response, accessibility needs, account recovery, administrator lockout, and provider outage. Record help-desk effects and false denials. A rollback plan should restore necessary access without abandoning auditability or creating a permanent bypass.
Phase 3: Reduce standing access and limit movement
Review application roles, shared folders, cloud groups, local administrator rights, vendor access, remote-management tools, and network paths. Remove access that is not needed for the user's current role. Segment access around business resources and administrative functions where it reduces meaningful exposure. Do not equate buying a SASE, identity, endpoint, or firewall product with completing zero trust.
CISA's federal Zero Trust Maturity Model Version 2 organizes progress across identity, devices, networks, applications and workloads, and data, with visibility, automation, and governance across them. A small business can borrow the categories without claiming federal maturity or attempting every capability at once.
Phase 4: Make policy observable and repeatable
Send relevant identity, device, administrative, and application events to a review process with a named owner. Define what triggers investigation, who can change policy, how emergency changes are documented, and how lessons update the backlog. Measure resource coverage and decision quality rather than the number of tools purchased.
Reasonable measures include critical resources with named owners, privileged roles reviewed on schedule, terminated identities disabled through the approved process, policy exceptions past review date, high-risk resources covered by tested conditions, emergency access tests completed, and access denials that disrupted approved work. Set targets from the organization's baseline and risk tolerance; do not adopt unsupported universal benchmarks.
Copy this phased backlog record
Use one backlog row per resource and access-policy improvement:
- Resource and business owner: what is protected and who decides its access requirements.
- Access population: workforce role, administrator, vendor, service identity, device class, or application.
- Current decision: how access is granted today and what evidence supports it.
- Target condition: the specific identity, device, privilege, network, application, or data rule to introduce.
- Risk addressed: the misuse, exposure, or unsupported trust assumption the change is meant to reduce.
- Dependencies: licensing, inventory, device enrollment, application support, staffing, communications, recovery, and vendor work.
- Pilot and rollback: users, success evidence, support owner, stop condition, and reversible change.
- Status and decision date: discover, design, pilot, enforce, observe, improve, defer, or accept.
Keep an exception register
An exception is a governed decision, not a quiet exclusion. Record the resource, requested access, policy not met, business reason, requester, approving risk owner, start and expiration dates, affected users or devices, compensating measures, monitoring, renewal criteria, and removal owner. Time-limit emergency and vendor exceptions. Review whether the workaround creates a shared account, unmanaged device path, permanent administrator, disabled monitoring, or recovery dependency.
CISA's small and medium-sized business resources offer practical starting tools for organizations with limited staff, including cloud-configuration and vulnerability services. Use available resources to strengthen evidence, but keep accountability for policy and exceptions inside the business.
What zero trust should not become
- A claim that the internal network, a managed device, or an authenticated user is automatically safe.
- A universal block policy deployed without pilots, recovery access, user communication, or support capacity.
- An identity-only program that ignores devices, service accounts, applications, data, vendors, and administrative tools.
- A permanent collection of exceptions with no accountable risk owner or expiration date.
- A vendor promise that replaces business ownership, architecture decisions, operational testing, and measurement.
Related implementation guides
Use the senior living zero trust deployment guide for that sector's operational constraints, the cloud access governance guide for SaaS approval and review, and the security KPI reporting playbook for leadership evidence. This page remains the general small-business phased operating model.