Before the deep dive
A help-desk technician restores access for someone who has replaced their phone. The ticket looks routine. But suppose the account belongs to an administrator who can change the policies protecting production systems—and the caller isn’t who they claim to be.
That support interaction may become a path into a far more privileged boundary. It isn’t a criticism of the technician: the problem is an account-recovery process that can transfer authority beyond what it was intended to permit. Okta documented this class of attack in 2023.
What Zero Trust changes—and what remains
Zero Trust limits the access implicitly granted because someone is on an internal network. Yet every explicit access decision still relies on components that establish identity, issue credentials, apply policy, and enforce it. NIST’s Zero Trust Architecture recognizes that these systems carry their own trust assumptions and dependencies.
Those dependencies matter in three different ways:
Redundant servers can keep a service running through an outage yet reproduce the same incorrect policy. A strong sign-in flow can also be bypassed if an administrator can issue accepted SSH credentials and reach a host through a separate management path. The surrounding administrative powers deserve as much scrutiny as the front-door access controls.
Choose one high-consequence production workflow. Trace both its normal and alternate access paths. Identify who can reset privileged authentication, change trusted issuers or policies, and issue credentials that the resource accepts. Ask which authority could bypass the rest without an independent safeguard.
Then pick one exposure to fix: assign an owner, agree on the safeguard, and define a test proving that the authority path has been constrained.
The complete analysis below examines the NIST architecture, Storm-0558, credential and session behavior, Cisco ISE’s distributed design, and a worked example that ranks actual remediation options.
GO DEEPER · COMPLETE ARTICLEFull technical analysisArchitecture, incident evidence, worked example, and 11 primary-source references OpenCollapse
Zero Trust reduces implicit access, but the systems and people that establish trust deserve the same scrutiny as the resources they protect.
An employee calls the IT service desk after replacing a phone. They can no longer complete multifactor authentication and need help restoring access.
The technician follows the established recovery procedure, verifies the information required by the organization, and resets the account’s authentication factors.
The caller is relieved. The technician has helped someone get back to work.
Now change one detail.
The caller is an impostor who has already obtained the account password and has managed to satisfy the recovery checks. The account belongs to an administrator capable of changing security policies protecting production infrastructure.
What appeared to be a routine support request has become a path to extraordinary authority.
This scenario is hypothetical, but the attack pattern is documented. In August 2023, Okta reported attacks in which threat actors persuaded IT service desks to reset MFA factors on highly privileged accounts. Compromised administrator access was subsequently used to alter privileges, reset other administrators’ authenticators, and establish attacker-controlled identity federation relationships. [10]
The technician didn’t intend to authorize access to production. The organization had created a process in which recovering an account could become a route to acquiring that authority.
This raises a question worth asking of any modern access architecture:
Who can change the rules governing access, and who can acquire the identities or credentials that hold that authority?
It’s a question that deserves particular attention as organizations adopt Zero Trust.
What the technician sees
A colleague needs help restoring MFA on a replacement phone.
A routine support requestWhat the architecture permits
Recovery may transfer control of an identity that can modify production access policy.
A privileged authority boundaryTwo Different Meanings of Trust
Zero Trust has become one of the defining principles of modern enterprise security. Its central idea is that access shouldn’t be implicitly granted because a user or device resides inside a particular network boundary.
NIST SP 800-207 establishes this principle around explicit authentication, authorization, and resource-focused access decisions rather than assumptions based on location or ownership. [1]
Yet the term trust has two different meanings that are worth separating.
The first is access trust: the conditions under which a subject is allowed to access a resource.
Traditional perimeter-oriented architectures often relied heavily on network location. Once a device entered the enterprise network, it might gain broad reachability, even where application-level authorization still applied.
Zero Trust reduces that assumption. Access decisions should reflect identity, authorization, resource requirements, and appropriate contextual evidence.
The second meaning is architectural reliance: our dependence on the systems responsible for establishing identities, issuing credentials, evaluating policies, and enforcing access decisions.
These systems must operate correctly and resist compromise for the access architecture to achieve its intended purpose.
Zero Trust reduces unjustified access trust while continuing to depend on the integrity of its supporting infrastructure.
NIST’s own architectural model acknowledges this distinction. SP 800-207 describes an implicit trust zone behind a policy enforcement boundary and says that zone should be as small as possible. [1]
NIST also recognizes the operational consequences of these dependencies. In Appendix B.4.7, it identifies interconnected Zero Trust components as a potential source of cascading failures affecting business processes. It calls for further investigation into architectural chokepoints and the effects of disrupted communication between components, while acknowledging that adopting Zero Trust may require organizations to revisit their continuity-of-operations plans. [1]
This isn’t an overlooked contradiction in the standard.
The engineering challenge is translating those recognized dependencies into decisions about architectural authority, independent safeguards, and recovery.
The Systems Behind an Access Decision
Consider a request to access a sensitive enterprise application.
An identity provider may authenticate the requesting user or supply a federated identity assertion. A credential issuer may establish cryptographic identities for workloads. Endpoint management may provide device posture information, while inventory and contextual services contribute evidence used during authorization.
The authorization infrastructure evaluates those inputs against enterprise policy.
NIST SP 800-207 distinguishes three logical functions:
Access decision · three logical functions
- The policy engine (PE) determines whether access should be granted, denied, or revoked.
- The policy administrator (PA) carries out the decision, including establishing or terminating access paths and potentially generating session-specific credentials.
- The policy enforcement point (PEP) enables, monitors, or terminates access to the protected resource.
The PE and PA together form the logical policy decision point. These components can be combined or distributed in different implementations. [1]
The distinction between identity and authorization matters.
An identity assertion may be authentic even when an account has been compromised. A device posture report may be stale. A policy engine may correctly apply a rule to inaccurate asset information.
NIST’s Digital Identity Guidelines address identity proofing, authentication, and federation, while resource authorization remains a decision made using the relevant identity evidence and applicable policy. [2]
NIST SP 800-207A further develops identity-based access approaches for cloud-native applications and services, where credential issuance and service identity become particularly important. [3]
These dependencies existed before Zero Trust. Directory services, VPN gateways, certificate authorities, and privileged administrators have long been central to enterprise access.
The important differences lie in how a particular architecture distributes authority, how broadly applications depend on shared services, and how failures propagate.
Centralized Governance, Distributed Consequences
Centralizing identity and policy governance can improve security.
Consistent policies reduce configuration differences between applications. Shared identity infrastructure can simplify lifecycle management. Centralized auditing can improve visibility and accountability.
But shared governance can also create shared dependencies.
Three architectural properties should be examined separately.
Three dimensions of shared dependence
Authority concentration describes how much control one administrator, credential, service, or management process can exercise.
Availability coupling describes how many resources or business workflows depend on a shared service remaining operational.
Failure correlation describes whether one defect, compromised credential, or configuration change can affect multiple components simultaneously.
An enterprise identity provider may improve authentication consistency while making more applications dependent on that provider during sign-in.
Moving away from network-location-based authorization may also reduce the authority available to someone who gains access to an internal network segment.
The net security outcome depends on the architecture and the controls it replaces.
Logical centralization also doesn’t require one physically centralized implementation.
NIST SP 800-207A describes coordinated enterprise policy alongside separate service-mesh control planes for individual clusters. This can limit certain availability failure domains while retaining consistent policy governance. [3]
Cisco Identity Services Engine (ISE) provides another practical example of separating centralized administration from distributed policy evaluation. In a distributed deployment, Policy Administration Nodes manage configuration while Policy Service Nodes (PSNs) evaluate network-access policies. Multiple PSNs can support scalability and availability, while configuration changes made on the primary Policy Administration Node are replicated to registered secondary nodes. [11]
The ISE deployment roles aren’t direct one-to-one equivalents of NIST’s logical PE, PA, and PEP functions. Nevertheless, the design illustrates how distributed policy evaluation can coexist with shared administrative control. It also raises an important consideration: distributing policy processing doesn’t inherently protect those nodes from incorrect or unauthorized configuration changes propagated through centralized administration.
However, deploying separate instances doesn’t automatically create independent security boundaries.
Two enforcement services in different regions may share administrative credentials, policy repositories, or faulty configuration updates.
Both can remain fully available while enforcing the same incorrect decision.
Availability redundancy and security independence are related but different architectural properties.
Three Ways Trust Infrastructure Can Fail
Unavailable
The service cannot be reached.
Evaluate continuity and recovery.
Incorrect
The service works, but its evidence or policy is wrong.
Validate inputs and change controls.
Compromised
An adversary influences decisions or authority.
Contain privileges and investigate trust.
A useful review distinguishes between infrastructure that is unavailable, infrastructure that is incorrect, and infrastructure that has been compromised.
Unavailable
An identity provider, policy service, credential issuer, or enforcement component cannot be reached.
New authorization requests may fail. Established sessions may continue, terminate, or require reauthorization depending on the implementation.
Recovery depends on which functions remain available and whether alternative administrative paths exist.
Incorrect
A component remains available but operates using faulty information or configuration.
A stale inventory classifies a critical production server as an ordinary workstation. A policy update distributes unintended privileges across several regions. A credential-validation rule accepts a signing authority outside its intended trust domain.
The components may report healthy status while producing inappropriate decisions.
Redundancy can reproduce the error rather than contain it.
Compromised
An attacker gains influence over a signing service, privileged administrator, policy repository, or enforcement mechanism.
The system may continue operating, but its decisions or the evidence supporting them can be manipulated.
Controls designed to preserve availability won’t necessarily prevent a privileged attacker from changing authorization policy.
NIST SP 800-207 explicitly discusses decision-process subversion and disruption of Zero Trust infrastructure. Appendix B.4.7 further identifies cascading dependencies and continuity planning as resilience concerns, while recognizing that the operational consequences of certain Zero Trust failure modes require additional research. [1]
Sessions, Credentials, and Cached Decisions
Failure behavior also depends on where authorization state resides.
An established application session may maintain its own state. An issued token or certificate may remain acceptable for some period. An enforcement point may separately retain cached authorization decisions or local policy.
These mechanisms operate differently.
OAuth defines token revocation and introspection mechanisms, but their effectiveness depends on implementation. RFC 7662 specifically recognizes that cached introspection results create a window during which a revoked token might still be accepted. [5][6]
Short-lived credentials can reduce the duration of certain exposures without guaranteeing immediate revocation.
NIST SP 800-207 doesn’t prescribe one outage response for every deployment.
For privileged administrative access, failing closed for new authorization may be appropriate. Lower-consequence workflows may justify limited continuity using previously validated authorization state.
The correct approach depends on the resource, operating conditions, and consequences of both granting and denying access.
These behaviors must be documented and tested rather than assumed.
Storm-0558: When a Trusted Credential Crossed the Wrong Boundary
The 2023 Storm-0558 intrusion provides a real-world example of how credential validation and identity infrastructure can undermine a broader security boundary.
According to the Cyber Safety Review Board’s 2024 report, the threat actor forged authentication tokens using a Microsoft consumer signing key created in 2016.
The intrusion affected Exchange Online mailboxes at 22 enterprise organizations and 503 related personal accounts worldwide. As of the report, Microsoft had not established how the actor obtained the signing key. [7]
The architectural issue extended beyond possession of the key.
Microsoft had introduced a common OpenID Connect endpoint that exposed signing-key information for both consumer and enterprise identity systems. The Board found that token-validation software had not been adequately updated to maintain the necessary distinction between the two sets of signing keys.
Consequently, tokens signed with a consumer key could be accepted by certain enterprise services under circumstances where they should have been rejected. [7]
This incident doesn’t establish that a particular Zero Trust implementation failed.
It illustrates why trust relationships must be examined across the systems responsible for issuing and validating credentials.
Protecting a signing key is essential. So is establishing which issuers and signing authorities a relying service is permitted to accept.
A cryptographically valid signature cannot establish appropriate authorization when the system accepts it under the wrong trust relationship.
This lesson becomes particularly important when examining the administrative processes that determine which identity providers, credential issuers, and federation relationships an enterprise trusts.
From Architecture Diagram to Trust Dependency Review
Threat modeling, attack-path analysis, administrative tiering, and dependency mapping are established engineering practices.
A Trust Dependency Review applies those disciplines specifically to the systems and authorities responsible for granting or changing access.
Its purpose is to identify consequential dependencies, evaluate their safeguards and failure modes, and produce a prioritized remediation decision.
Start with one high-consequence business workflow.
Before examining its normal access path, determine whether alternative paths exist.
An identity-aware gateway may govern standard administrative access, while direct SSH, cloud management APIs, service accounts, orchestration platforms, or emergency credentials provide additional legitimate routes.
A well-controlled primary path doesn’t establish that the resource has no alternative route around those controls.
Then evaluate five questions.
What authority exists?
Identify the human administrators, service accounts, credential issuers, policy repositories, and automation pipelines capable of materially changing access.
Include authority to modify trusted identity providers, federation relationships, accepted signing keys, credential-issuance policies, and emergency-access mechanisms.
A component doesn’t need to process substantial application traffic to hold consequential authority.
A rarely used administrative credential may affect thousands of resources.
What evidence supports the decision?
Identify the identity assertions, credentials, endpoint posture information, asset classifications, and policy state used during authorization.
Determine who can change those inputs and how their integrity and freshness are established.
A correctly functioning policy engine can still reach an incorrect conclusion using compromised or inaccurate evidence.
How far can failure propagate?
Examine shared control planes, administrative privileges, signing authorities, deployment pipelines, and configuration repositories.
Determine whether supposedly independent systems share authority or dependencies that could cause correlated failure.
What happens when a dependency is unavailable, incorrect, or compromised?
Evaluate these conditions separately.
For unavailability, examine new authorization requests, established sessions, previously issued credentials, cached decisions, and revocation.
For incorrect operation, examine how faulty policy and evidence are detected, corrected, and rolled back.
For compromise, determine how malicious changes are contained and compromised credentials or administrative privileges are invalidated.
Then ask:
Can the system be recovered without relying on the component that has failed?
Emergency access that requires an unavailable identity provider to authenticate is not independent of that provider for that failure scenario.
Emergency paths also introduce privileged authority requiring their own credential protection, restrictions, monitoring, and testing.
Microsoft’s Entra emergency-access guidance illustrates how organizations can protect recovery paths against federation outages and certain authentication failures. Those emergency accounts still depend on Microsoft Entra ID itself and should not be described as independent of a complete Entra platform outage. [9]
Who owns the boundary?
Identify who approves authorization policy, manages sensitive credentials, deploys changes, and accepts residual risk.
Include non-human administrative identities and automation.
Policy-as-code repositories, deployment pipelines, and infrastructure-management accounts can hold privileges as consequential as those of human administrators.
Separate the authority to request access from the authority to change the rules governing access.
What Makes a Safeguard Independent?
The review needs a practical way to distinguish meaningful separation from controls that merely appear independent.
A safeguard should be assessed against the failure or attacker capability it is intended to constrain.
Two administrators approving a change may provide limited independence if one compromised authority can impersonate both approvers or modify the approval process.
Similarly, requiring MFA for privileged administrators provides weaker separation if the same compromised recovery authority can reset or replace those administrators’ authentication methods.
An independent preventive safeguard should resist bypass through the authority it is designed to constrain.
That may require separate administrative control, independently protected credentials, or enforcement mechanisms that cannot be modified through the original privilege path.
Independence doesn’t necessarily require entirely separate infrastructure. It must be demonstrated against the threat being evaluated.
Monitoring and alerting remain valuable, but detective controls aren’t equivalent to preventive authorization barriers. Depending on the consequences of an action, a bounded and rapidly detectable failure may be acceptable without another preventive control.
Two different safeguards
Constrains or blocks the authority path before it can be exercised.
Reveals inappropriate activity so investigators can respond; it does not automatically prevent the first action.
Some concentrated privileges are also intentional, including emergency-access accounts.
The review should evaluate their compensating controls rather than automatically treating concentration as a defect.
The next step is to prioritize authority that can materially affect the workflow without adequate safeguards, considering exposure, plausible attack paths, business impact, existing protections, and recoverability.
A Worked Example: Privileged Access to Production
Normal approved path
Discovered alternate path
Consider a hypothetical production-access workflow.
An engineer authenticates through an enterprise identity provider using MFA, requests elevated access through a privileged-access platform, connects through an identity-aware gateway, and receives a short-lived SSH certificate to access a production host.
The architecture includes several strong controls.
Now examine the authority behind those controls.
Finding 1: Identity Recovery Can Reach Policy Administrators
The IT service desk can reset authentication methods for accounts that administer the identity-aware gateway.
Even though the service desk cannot directly modify the gateway’s policy, an attacker who obtains a privileged administrator’s password and successfully manipulates the recovery process may be able to take control of that administrator’s account.
The attack crosses the boundary indirectly.
This resembles the class of attack described in Okta’s 2023 advisory, where help-desk recovery procedures were exploited to compromise highly privileged identities. [10]
Simply assigning MFA recovery and policy administration to different groups wouldn’t fully address this risk.
The recovery process must be constrained so that a compromised help-desk role cannot assume the identity of a gateway-policy administrator, signing-authority administrator, or other sensitive privileged account.
Finding 2: A Signing Authority Can Bypass the Normal Access Path
Suppose the review discovers that a cloud administrative role can invoke the SSH signing service to issue certificates containing principals accepted for privileged host access.
Further investigation identifies a separate management network through which that role can reach the production hosts without traversing the identity-aware gateway.
The hosts trust the issuing CA for the relevant accounts, and no independent host-side restriction prevents this access under the assumed configuration.
This creates a potentially direct path around the identity provider, privileged-access workflow, and normal gateway controls.
OpenSSH supports trusted certificate authorities and restrictions on accepted certificate principals. But those restrictions alone do not prevent a compromised signing service from issuing certificates containing accepted principals when the attacker controls issuance. [8]
An administrator who cannot extract a private signing key may still misuse the signing service if they have unrestricted authority to request signatures.
Controls protecting key material and controls governing certificate issuance address related but different risks.
Independently administered host or network policies could further restrict which accounts or source networks may reach SSH. This hypothetical assumes those controls do not block the identified alternate management path.
In this hypothetical, the combination of issuance authority and alternate management connectivity is particularly consequential.
Finding 3: Emergency Recovery Depends on the Primary Identity System
The organization also discovers that emergency administrator access to the privileged-access platform requires authentication through the same identity provider whose outage the recovery process is supposed to address.
Application infrastructure may be redundant, yet administrators could lose access to the tools needed for recovery.
An emergency-access design must therefore consider which dependencies it is intended to survive and what additional risks the alternative path introduces.
Choosing What to Fix First
The Trust Dependency Review should end in a decision.
For this hypothetical, I would initially prioritize Finding 2: unrestricted SSH credential issuance combined with an alternate route to production.
Under the stated assumptions, this path may allow one compromised administrative authority to obtain privileged host access without passing through several of the controls that appear in the normal access workflow.
The first remediation would be to constrain the signing service’s authority and close or appropriately protect the alternate management path.
That might involve separating general cloud administration from certificate-issuance authorization, enforcing issuance policy through an independently protected mechanism, and ensuring alternative management access receives equivalent authentication and authorization protections.
Separate issuing authorities for distinct environments may also reduce the scope of compromise, where appropriate.
The responsible security architecture and infrastructure owners would need to validate the exact attack path before finalizing the design.
A meaningful verification test would demonstrate that compromising the identified cloud administrative role alone cannot obtain an accepted privileged certificate and reach the production host through any of the identified management paths.
Finding 1 becomes the next priority under these assumptions.
The remediation should prevent the MFA-recovery role from resetting or replacing authentication methods for privileged policy, signing, or recovery administrators through direct or transitive administrative permissions.
The verification test must cover both direct role assignment and account takeover through recovery or delegated administration.
The test should also confirm that the recovery role cannot create or modify a trusted identity provider or federation relationship that could be used to impersonate privileged administrators.
Finding 3 remains an important resilience issue. It should produce a tested emergency-access process with appropriately independent dependencies and compensating security controls.
These priorities are illustrative.
If the signing service were already independently constrained or the alternate management route did not exist, the ranking could change. A critical recovery dependency might also warrant earlier remediation where prolonged loss of administrative access would create unacceptable consequences.
The review should make those assumptions explicit rather than treating its rankings as universal.
Decision artifact · hypothetical priority order
| Priority | Finding | Why it matters | First action |
|---|---|---|---|
| 01 | SSH signing authority and alternate production path | Under the stated assumptions, one role could obtain accepted credentials and bypass standard access controls. | Constrain certificate issuance and protect every alternate management path. |
| 02 | MFA recovery reaches privileged administrators | Account recovery could be a transitive route into gateway, signing, or federation authority. | Independently restrict recovery of privileged accounts and federation changes. |
| 03 | Emergency access depends on primary IdP | A failure of the primary identity service could prevent restoration of privileged access. | Establish and periodically test a protected recovery path for defined failures. |
Its final output should identify:
- The authority path or dependency that creates the risk.
- The evidence supporting the finding and its priority.
- The accountable owner and selected remediation.
- The verification needed to demonstrate that the exposure has been reduced.
The objective is a defensible engineering decision, not simply another completed assessment.
The Trust Behind Zero Trust
A Trust Dependency Review may result in stronger administrative separation, independent credential-issuance controls, improved monitoring, or more resilient recovery mechanisms.
It may also conclude that an existing centralized system has adequate safeguards and that introducing additional components would create more complexity than benefit.
Both outcomes are useful.
NIST’s Zero Trust implementation guidance recognizes that different enterprises require different deployment architectures. There is no single configuration appropriate for every organization’s risks and resources. [4]
The important measure is whether the selected architecture protects the workflows that matter and adequately constrains the authority on which those protections depend.
Consider the service-desk technician from our opening.
The objective isn’t to make that person reluctant to help someone who has lost access. It’s to design recovery procedures that let them do their job without unintentionally transferring authority over critical systems.
The same principle applies to credential issuers, automation pipelines, administrators, and policy engines.
A component’s security responsibilities aren’t defined only by what it normally does. They also depend on what someone controlling it could cause other systems to accept or execute.
For your next architecture review, choose one critical production-access workflow and identify the authority capable of changing its access decisions.
Examine alternate access paths, trusted issuers, administrative recovery, and common failure dependencies. Select the highest-consequence inadequately constrained path, assign an owner, and establish a test that demonstrates whether the remediation actually works.
The most consequential trust dependency may not be the gateway protecting an application. It may be the credential, administrator, or automation process capable of changing what that gateway permits.
The question worth asking is whether those dependencies have received the same scrutiny as the resources they’re supposed to protect.
References
- Rose, S., Borchert, O., Mitchell, S., and Connelly, S. (2020). Zero Trust Architecture. NIST SP 800-207. Sections 2, 3, 5, and Appendix B.4.7. https://doi.org/10.6028/NIST.SP.800-207
- National Institute of Standards and Technology. (2025). Digital Identity Guidelines. NIST SP 800-63-4, Section 2.5. https://doi.org/10.6028/NIST.SP.800-63-4
- Chandramouli, R., and Butcher, Z. (2023). A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments. NIST SP 800-207A. https://doi.org/10.6028/NIST.SP.800-207A
- National Institute of Standards and Technology. (2025). Implementing a Zero Trust Architecture: High-Level Document. NIST SP 1800-35. https://doi.org/10.6028/NIST.SP.1800-35
- Lodderstedt, T., Dronia, S., and Scurtescu, M. (2013). OAuth 2.0 Token Revocation. RFC 7009. https://www.rfc-editor.org/rfc/rfc7009
- Richer, J. (2015). OAuth 2.0 Token Introspection. RFC 7662. https://www.rfc-editor.org/rfc/rfc7662
- Cyber Safety Review Board. (2024). Review of the Summer 2023 Microsoft Exchange Online Intrusion. U.S. Department of Homeland Security. Official publication: https://www.cisa.gov/resources-tools/resources/cyber-safety-review-board-releases-report-microsoft-online-exchange-incident-summer-2023 Original report (PDF): https://www.cisa.gov/sites/default/files/2024-04/CSRB_Review_of_the_Summer_2023_MEO_Intrusion_Final_508c.pdf
- OpenBSD Project. sshd_config(5) — OpenSSH Server Configuration Manual. See
TrustedUserCAKeys,AuthorizedPrincipalsFile, andAuthorizedPrincipalsCommand. https://man.openbsd.org/sshd_config - Microsoft Learn. Manage Emergency Access Admin Accounts in Microsoft Entra ID. https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access
- Okta Security. (August 31, 2023). Cross-Tenant Impersonation: Prevention and Detection. https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection/
- Cisco Systems. (2026). Cisco Identity Services Engine Administrator Guide, Release 3.5 — Deployment of Cisco ISE. Updated October 12, 2026. https://www.cisco.com/c/en/us/td/docs/security/ise/3-5/admin_guide/b_ise_admin_3_5/b_ISE_admin_deployment.html
Leave a Reply