Do it whenever external access can reach engineering, supervisory, or production systems and does not need to remain open continuously. If a vendor connection is only needed for maintenance, troubleshooting, or periodic review, it should be time-bounded and explicitly approved rather than permanently trusted.
Why This Matters for Security Teams
Always-on vendor access is a standing trust decision, not a convenience feature. When external parties can reach engineering, supervisory, or production systems continuously, the organisation inherits their security posture, their session hygiene, and their offboarding discipline. That is especially dangerous for non-human identities, where long-lived access often outlasts the business need. NHI Mgmt Group notes that 92% of organisations expose NHIs to third parties, which makes vendor pathways a common supply-chain entry point. See the Ultimate Guide to NHIs for the broader lifecycle context, and the OWASP Non-Human Identity Top 10 for common control failures.
The practical question is not whether a vendor is trusted, but whether access must remain continuously available to keep the service functioning. If the answer is no, the access should be scheduled, approved, and revoked automatically when the window ends. In practice, many security teams encounter vendor overexposure only after an audit finding, a dormant account review, or a third-party incident has already created urgency rather than through intentional access design.
How It Works in Practice
Scheduled access converts a permanent entitlement into a time-bounded operational workflow. The team defines when the vendor is allowed in, what systems are in scope, who approves the window, and how access is withdrawn. This is most effective when paired with just-in-time credential issuance, short TTLs, and explicit session logging. Current guidance suggests treating the vendor as a temporary non-human operator, not a standing member of the internal trust zone.
A workable model usually includes:
- Requester identity verification and ticket linkage before activation.
- Approval based on business need, asset criticality, and change window.
- Ephemeral credentials or bastion-mediated access that expire automatically.
- Session recording, command logging, or tool-level audit trails.
- Automatic revocation at window close, with reapproval required for the next session.
For vendor sessions that touch production, this should map to a stronger control plane, not just a calendar reminder. Zero Trust principles and workload-style access patterns support this approach, especially where secrets management and access governance are already centralised. The Ultimate Guide to NHIs — Key Challenges and Risks covers the risk of persistent credentials, while the OWASP Non-Human Identity Top 10 is a useful reference for rotation, visibility, and offboarding gaps. These controls tend to break down when a vendor must maintain continuous telemetry, emergency support, or machine-to-machine integrations that cannot tolerate downtime because the business keeps confusing operational continuity with permanent trust.
Common Variations and Edge Cases
Tighter vendor access often increases coordination overhead, requiring organisations to balance reduced exposure against response speed. That tradeoff is real: scheduled access can slow emergency support if the approval chain is too rigid, or if the vendor lacks a fast reactivation path during incidents. Best practice is evolving, but current guidance generally favours standing exceptions only when there is a documented, continuous operational requirement.
There are a few important edge cases. Some vendor tools need persistent connectivity for monitoring, patch orchestration, or alert delivery. In those cases, the goal is not to force schedule-based access onto the tool itself, but to narrow the scope to the minimum reachable asset set, isolate the pathway, and enforce rotating secrets and strong monitoring. Other environments rely on legacy remote support platforms that do not support JIT well; those should be treated as temporary technical debt with a migration plan, not a permanent exception.
The strongest policy is usually one that distinguishes between breach patterns seen in third-party NHI incidents and genuinely continuous service dependencies. If the vendor does not need uninterrupted access to keep the business running, scheduled access is the safer default. If it does, the access path should still be segmented, monitored, and reviewed on a fixed cadence rather than left open indefinitely.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses long-lived vendor secrets and poor rotation that scheduled access is meant to replace. |
| NIST CSF 2.0 | PR.AC-4 | Directly supports least-privilege, time-bounded access for third-party users and services. |
| NIST Zero Trust (SP 800-207) | Scheduled access aligns with continuous verification and reduced trust for external parties. |
Replace standing vendor credentials with short-lived access and enforce rotation or revocation on every approved window.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
