They should reduce the blast radius before granting access by limiting scope, separating environments, and making revocation executable from day one. Persistent connectivity is not the same as persistent trust. The organisation still needs narrow permissions, monitored activity, and an explicit exit path so the relationship can be terminated without orphaned access.
How to treat persistent supplier connectivity without turning it into open-ended trust
Persistent access is a business arrangement, not a security entitlement. The right question is not whether the supplier needs connectivity, but how to let them perform a defined operational function without creating standing access that outlives the job, the environment, or the risk case. That means constraining where they can go, what they can change, and how quickly access can be shut off.
Persistent connectivity is also where many organisations blur operations with privilege. If the supplier must remain reachable, the access path should still be designed as if it may one day be abused, misrouted, or left behind. That is why the access model should be narrow, segmented, and revocable, rather than broad, shared, or permanent.
Where the operational model depends on trusted remote access, the control baseline should still reflect least privilege and segmentation. The NCSC UK Advice and Guidance and SANS Security Resources both reinforce the practical principle: keep remote administration tightly scoped, monitored, and separate from ordinary business access so that one supplier relationship cannot become a broad trust boundary.
Design the access so it can be withdrawn, bounded, and audited
Organisations should define the supplier's access as an operating pattern with controls attached, not as a permanent exception. The boundary should include named systems, named purposes, time or workflow limits where possible, and a clear revocation path that does not depend on tribal knowledge. If the supplier relationship ends, the organisation should be able to disable the access cleanly without hunting through inherited accounts, VPN exceptions, or shared passwords.
Separation of environments matters because persistent access becomes much riskier when the same path can touch production, test, and administrative tooling. A supplier that needs ongoing connectivity for operations should not automatically receive lateral reach into unrelated systems. Segmented access, distinct accounts, and explicit environmental boundaries reduce the chance that a single compromise or mistake spreads across the estate.
Monitoring is part of the design, not an afterthought. Persistent connectivity should be attributable to a specific supplier identity, logged, and reviewable in a way that supports both incident response and routine assurance. If the organisation cannot tell what the supplier touched, when, and from which path, then the access is effectively more trusted than the business justified.
What to do when the supplier's access is operationally necessary but hard to replace
Some supplier connections are difficult to remove because they support production stability, managed services, or long-running integrations. In those cases, the safest move is to treat the connection as a controlled dependency with a documented exit path, not as a reason to relax controls. Build the revocation step first, even if day-to-day operations are expected to continue.
That usually means assigning ownership for the access, defining the exact business purpose it serves, and making sure the access model can be rotated, re-approved, or disabled without restarting the service relationship. If the supplier uses credentials, sessions, or keys to maintain connectivity, those should be capable of independent rotation and replacement. The point is to avoid a setup where continuity depends on a secret or account that nobody can safely retire.
A useful operating rule is to distinguish service continuity from privilege continuity. A supplier may need persistent connectivity, but that does not mean the same level of access should remain unchanged forever. Mature access governance revisits scope, auditability, and termination handling on a recurring basis, especially when the supplier is supporting critical systems.
Risk and Threat Considerations
Persistent supplier access concentrates exposure because a relationship created for operations can become a durable foothold if the account, credential, or remote path is overbroad or left in place after the need changes. The main risk is not the existence of connectivity itself, but the combination of standing access, weak segmentation, and poor revocation discipline.
Failure mechanism: An attacker, compromised supplier endpoint, or disgruntled insider can reuse the trusted path to move laterally, access more systems than intended, or continue operating after the business no longer needs the connection. If the organisation cannot segment the supplier into a narrow operational lane, the access path can become a high-blast-radius trust channel.
Impact: The likely outcomes are unauthorized access, slower containment, harder incident scoping, and an orphaned trust relationship that survives personnel changes, contract changes, or environment changes. In the worst case, the access remains valid long enough for a compromise to look like normal supplier activity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Persistent supplier access should be narrowly scoped to limit blast radius. |
| AC-20 — Use of External Information Systems | Supplier connectivity is a third-party access path that needs explicit conditions and oversight. | |
| IA-5 — Authenticator Management | Persistent connectivity often depends on credentials or keys that must be rotated and revoked cleanly. | |
| Recommendation — Apply AC-6 to limit supplier permissions to the minimum operational need. Control external supplier access with documented terms and monitored use conditions. Manage supplier authenticators so access can be rotated or revoked immediately. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The question is about limiting trust while allowing ongoing access through bounded verification. |
| Recommendation — Treat every supplier session as explicitly verified and continuously constrained. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Supplier access must be provisioned, scoped, and removed with clear ownership. |
| Recommendation — Manage supplier access centrally and remove it promptly when the need ends. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Persistent connectivity requires governed access, not informal trust expansion. |
| Recommendation — Enforce access governance so supplier connectivity stays bounded and attributable. | ||
Practitioner Guidance
What to verify: Confirm that the supplier's access is tied to a named business function, not a generic support relationship. Verify that the organisation can revoke access immediately, including any supporting sessions, keys, VPN routes, or shared administrative paths.
Decision rule: If the supplier needs persistent connectivity to keep operations running, treat the access as a controlled dependency and require segmentation, narrow permissions, and auditable ownership before go-live. If those controls cannot be made operational, the access model is too broad for a durable relationship.
What good looks like: The supplier can do the required work, but only through a constrained path, only against the intended systems, and only with an exit path that can be executed without delay or guesswork.
Practitioner takeaway: Persistent connectivity is acceptable only when the organisation can prove that trust is bounded, observable, and removable on demand.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org