Zero trust is most useful when it is treated as a set of testable access assumptions rather than as a product category. The current 350-701 SCOR v2.0 blueprint includes zero-trust architecture, Cisco Duo Trust Monitor, MFA, Device Trust, health checks, Adaptive Access, SSO, secure private access, secure internet access, posture, and network access controls. The architecture should therefore be judged by the evidence it requires before granting access and by how quickly access changes when that evidence changes.
The core idea in zero-trust security is that network location alone is not sufficient proof of trust. A user inside the office can have stolen credentials; a managed device can become compromised; a remote user can be legitimate and still need only one application.
A Cisco environment may combine Duo identity/context, ISE/NAC, Secure Access, Secure Client, firewalls, segmentation, endpoint protection, and telemetry. The design should avoid assuming that owning all those controls automatically creates zero trust. Their decisions need to reinforce one another.
Define the protected resource before the user population
Zero-trust policy is easiest to design around resources: which application, administrative interface, dataset, or service is sensitive, who needs it, and under which conditions?
Starting from ’employees are trusted’ creates broad access. Starting from ‘finance analysts on compliant devices need this finance app’ creates a testable authorization rule.
Resource-centric policy also makes exceptions smaller because temporary access can be granted to one application instead of to a whole internal network.
Resource definitions should include data and administrative interfaces as separate protected objects. A user may be allowed to consume an application and not administer it; an engineer may manage infrastructure and not read business data. Zero-trust policy becomes clearer when those permissions are not collapsed into one broad ‘app access’ decision.
Resource-centric policy also helps during mergers and contractor access. New populations can be granted access to defined applications without inheriting the network relationships of long-standing employees. That limits the amount of legacy trust that must be extended before the organization understands the new user’s full environment.
Identity strength must match resource sensitivity
MFA can reduce risk from stolen passwords, but not every MFA method provides the same phishing resistance or assurance.
Privileged access should use stronger authentication and tighter session policy than low-risk application access.
The broader role principles in RBAC help define who should request the resource; zero-trust context adds conditions about device, session, location, and risk before the role becomes usable.
Identity assurance should be revisited for recovery paths. Help-desk password resets, lost MFA devices, and break-glass credentials can weaken an otherwise strong authentication design. Attackers often target recovery processes precisely because the primary login path is hardened.
MFA policy should test push-fatigue and recovery abuse, not only whether a second factor exists. Number matching, phishing-resistant methods, device binding, and risk-based step-up can improve assurance, while a weak help-desk reset path can undo those gains.
Device trust should be evidence, not a permanent label
Security posture assessment can contribute evidence such as encryption, security-agent status, OS version, certificate, or management state.
Those attributes can change after login, so a device should not remain trusted indefinitely because it passed a check last week.
Decide which health failures deny access, which trigger remediation, and which only increase monitoring. The policy should reflect business consequence.
Device-trust systems should distinguish corporate ownership, management enrollment, and current health. A personally owned device with an installed security agent is not equivalent to a fully managed corporate endpoint, and a corporate device whose management agent is stale may deserve lower trust than its ownership label implies.
Device-trust policy should also handle virtual desktops, shared workstations, and service accounts that do not fit the normal one-user/one-device assumption. The architecture should define equivalent evidence for those cases rather than forcing them through exceptions that bypass normal controls.
NAC and application access solve different scopes
Network access control can restrict whether and how a device joins a wired or wireless network. Secure private access can restrict which private applications a user can reach after authentication.
Using both can create defense in depth: the endpoint receives limited network placement and still must satisfy application-specific policy.
Do not make one control redundant by granting broad network reach once NAC succeeds. Network admission and application authorization should have distinct purposes.
NAC should also test lateral movement after admission. A managed user device that is correctly authenticated may still be compromised and should not automatically reach peer endpoints, management networks, or sensitive server tiers. Access policy should remain least-privilege after the first gate is passed.
Application-specific access should be tested for unintended transitive reach. A user granted access to a jump host may effectively reach every system the jump host can administer. The protected resource is therefore the full downstream capability, not just the first application icon shown to the user.
Remote and campus users should face consistent policy goals
Office users often inherit strong network connectivity by default, while remote users traverse VPN or cloud access services. Zero trust should reduce that location-based difference.
Policy can still account for location as context, but being on campus should not become a substitute for identity, device health, and resource authorization.
The architecture shift behind SASE is relevant because cloud-delivered policy can apply to remote and branch users without backhauling every access decision through one data center.
Location should be treated as context rather than identity. An on-campus connection may reduce some risks and increase others, such as unmanaged devices attached to internal ports. Remote access may have stronger device posture and MFA than legacy local access. Policy should compare evidence instead of assuming office equals trusted.
Trust should be reevaluated when risk changes
Duo Trust Monitor, endpoint detections, identity anomalies, posture changes, or security telemetry can indicate that a previously valid session is now riskier.
The response could require step-up authentication, session termination, reduced access, endpoint isolation, or investigation depending on severity and platform capability.
Continuous evaluation only works if the signals reach the policy or response system quickly enough to matter.
Continuous evaluation should have action thresholds. Low-confidence risk may increase logging; medium risk may require step-up authentication; high-confidence endpoint compromise may terminate sessions and isolate the device. Without predefined responses, risk signals become dashboards rather than enforcement inputs.
Continuous risk signals should have freshness and source-quality expectations. A posture result from yesterday or an identity-risk score that has not updated because telemetry failed should not be treated as current evidence. Policy needs expiry and degraded-state behavior for contextual signals.
Segmentation limits what a stolen session can reach
Least-privilege application access reduces blast radius, and network/workload segmentation adds containment when an endpoint or application is compromised.
Zero trust does not eliminate the value of firewalls, SGTs, VLANs, microsegmentation, or workload policy. It changes the assumption that being in one segment is permanent proof of legitimacy.
Use the simplest control that can enforce the relationship while preserving clear evidence.
Segmentation policy should also consider service-to-service and workload identity. Zero trust is not only about employees connecting to applications. APIs, automation, cloud workloads, and infrastructure services need identities and least-privilege relationships that can be revoked independently.
Workload identity needs the same lifecycle rigor as human identity. API tokens, certificates, service accounts, and machine credentials should be rotated and revoked when deployments change. Zero trust loses credibility if human access is conditional while long-lived machine secrets remain broadly trusted.
Failure modes are part of the trust model
What happens if Duo is unreachable, ISE loses an identity source, Secure Access has a regional service problem, endpoint posture cannot be collected, or a certificate expires?
A fail-open design improves availability and can destroy the security objective; a fail-closed design protects resources and can create a business outage.
Define fallback per resource and user population. Break-glass access should be narrow, monitored, and tested rather than improvised.
Fail-open/fail-closed decisions should be revisited per resource. Public marketing content, employee collaboration, privileged administration, and payment systems have different availability/security trade-offs. One global fallback policy usually overprotects low-risk services or underprotects high-risk ones.
Test assumptions with adversarial scenarios
Use the strategic perspective in zero-trust architecture and test concrete abuse paths: stolen password, MFA fatigue, unmanaged device, compliant-but-compromised endpoint, spoofed device identity, insider on campus, remote contractor, stale posture, and failed policy service.
For each scenario, record which signal changes the decision, where enforcement occurs, what telemetry is produced, and who responds.
The current CCNP Security zero-trust objective is met when the organization can prove that identity, device trust, least privilege, segmentation, continuous evidence, and controlled failure behavior all support the same access decision—not when a dashboard simply says zero trust is enabled.
Zero-trust metrics should measure the assumptions: MFA strength, managed-device coverage, stale posture, least-privilege policy exceptions, broad network access, session reevaluation, bypass usage, unknown identities, and time to revoke access after risk changes. Progress is the reduction of implicit trust, not the number of products deployed.
A zero-trust review should include exception age and breadth. Legacy VPN groups, local admin accounts, unmanaged-device allowances, shared service credentials, bypassed posture, and network any-any rules are measurable pockets of implicit trust. Reducing those exceptions over time is a concrete sign that the architecture is maturing.
A mature program should test one assumption at a time and record whether the result matches policy. Stolen password plus compliant device, valid user plus unmanaged device, on-campus insider, compromised service account, and failed posture service each reveal a different dependency. Those tests turn zero trust from architecture language into measurable control behavior.
