- Define access decisions for a specific service rather than buying a company-wide label.
- Test denied access and alternate routes, not just successful sign-ins.
- Keep emergency access, workload identities, and support procedures in scope.
A mid-sized company does not need to redesign every network before improving access control. Choose a service where misuse would cause a clear business problem, such as payroll or cloud administration, and define who should reach it under which conditions.
NIST SP 800-207 describes Zero Trust as removing implicit trust based solely on location or ownership. It is an architectural approach, not a product that certifies the rest of the environment as safe.
Write the access decision first
For a hypothetical payroll application, the intended rule might require a current payroll role, approved authentication, and a managed device for administrative actions. A supplier may need temporary support access with a named sponsor. A scheduled integration needs its own narrowly scoped identity.
Record the business reason for each path. Separate ordinary use from administration and bulk export. Decide which conditions should deny access, which require stronger authentication, and which need an explicit exception. Product and licensing limits may require a staged implementation.
Map every actual route to the service: SSO, direct local login, VPN, support portal, API, and emergency account. A strong policy on the main login path is incomplete if a local account or integration bypasses it.
Pilot with evidence and a rollback plan
Begin with test identities and a small approved user group. Use supported evaluation or report-only capabilities where available, then move to enforcement after reviewing expected business cases. Identify who can recover access if the policy behaves unexpectedly.
Test both permitted and prohibited requests. An authorized payroll user on the expected device should succeed. A departed test identity, unapproved supplier, or disallowed device should receive the intended result. Record the event showing which policy made the decision.
Do not claim device checks prevent all compromise. They add context to an access decision; the device, identity, or session can still require investigation. Keep policy change and sign-in records available to responders.
Restrict what remains reachable
After sign-in, check the scope of access. Can an ordinary user reach administrative endpoints? Does a workload identity have broader database access than its task needs? Can a supplier session reach unrelated systems?
Use application permissions and network boundaries appropriate to those paths. Test the boundary from an authorized test environment. For legacy applications that cannot enforce the desired conditions themselves, document the compensating access layer and its limitations.
Avoid building permanent exceptions into the rollout. Each exception needs an owner, permitted scope, reason, and review date. Include emergency access in testing while protecting it from routine use.
Make the change supportable
Ask the help desk to work through a lost device, a traveling employee, and an expired supplier assignment. Explain the approved recovery and escalation route. If legitimate work repeatedly requires bypassing policy, examine the rule and workflow rather than normalizing bypasses.
Before expanding to another service, review the pilot's denied requests, support incidents, untested paths, and remaining standing privileges. Compare those results with the intended rule. Success means the service owner can explain who has access, why, and how that access is removed.
Keep the resulting access map and test record small enough to update after an application change. Broader identity lifecycle controls help prevent the same stale permissions from returning after the pilot ends.
Turn this identity guidance into a review of MFA strength, privileged access, lifecycle controls, and audit visibility.