Make it per job. Persistent contractor access is difficult to justify when interventions are intermittent, asset-specific and time-bounded. Per-job access gives operations the speed they need while keeping privilege tightly aligned to the maintenance window.
Why per-job access fits contractor work better than persistence
Contractor access usually exists to complete a defined task, on a defined asset, within a defined time window. That makes it a poor candidate for standing entitlement. If access remains persistent, the organisation is carrying an avoidable exposure between jobs, even when the contractor is no longer scheduled to touch the system. The safer default is to bind access to the job, then remove it when the job closes.
Per-job access also creates a clearer ownership model. Someone has to sponsor the access, define the scope, and confirm when the work is finished. That discipline prevents the common failure mode where a contractor is kept “just in case” and the exception becomes the normal operating state.
For contractors working across multiple systems, per-job access does not have to mean slow manual approvals every time. It can still be repeatable and efficient if the entitlement package is pre-defined, the approval path is standardised, and the access window is short enough to match the work order.
What persistent contractor access changes in practice
persistent access changes the blast radius of a mistake, a stolen credential, or a forgotten account. A contractor who no longer needs access can still use it, and an attacker who obtains that access inherits the same standing privilege until someone notices. That is why the Third-Party, B2B and Contractor Access Guide treats time limits, sponsorship and least privilege as core controls, not optional refinements.
It also weakens review quality. Access recertification works best when reviewers can answer a simple question: does this person still need this access for active work? If the answer is “maybe later”, the review becomes subjective and stale access is more likely to survive. The Contractor Identity Lifecycle Guide is useful here because it frames expiry, reviews and offboarding as lifecycle events rather than one-time onboarding checks.
Persistent access is especially risky when contractors touch privileged consoles, support tools, cloud tenants or shared admin paths. In those cases, standing access can outlive the business need and also outlive the trust assumption behind it. The Vendor Privileged Access Management Guide shows why brokered, approved, time-limited sessions are a better fit than always-on administrative access.
How to run per-job access without slowing operations
The key design choice is to pre-engineer access so that each job is fast to open and fast to close. That usually means a sponsor, a standard request type, a defined scope, and a fixed expiry tied to the work order or maintenance window. If the request does not map cleanly to a specific job, treat it as a sign that the access model is too broad.
For repeat contractors, build a reusable entitlement pattern rather than a reusable account. That lets the organisation preserve speed while still forcing a fresh decision each time the work is authorised. When the task is remote support or external administration, the ZTNA Guide is a strong fit because per-application policy and posture checks support access that is narrower than a broad VPN path.
If contractors need access to production secrets, tokens or service credentials, the access window should be even shorter and the handoff more controlled. In that situation, the question is not whether the contractor is trusted in general, but whether the specific job justifies the specific privilege for the specific duration. If it does not, split the task or move it to a safer support path.
Risk and Threat Considerations
Persistent contractor access turns a time-bounded business need into a standing exposure. The main risk is not only overuse by the contractor, but reuse by anyone who later obtains the account, session, or associated credentials. That creates unnecessary lateral movement potential and makes it harder to prove that access was still justified at the time of use.
Failure mechanism: Standing contractor accounts, retained roles, and long-lived support paths survive job completion, so the access remains valid after the business need has ended. Weak expiry discipline, poor offboarding, and shared admin pathways make that persistence exploitable.
Impact: Unneeded access increases the chance of unauthorised changes, data exposure, and privileged misuse, and it also increases the cleanup burden when teams later discover that the contractor should no longer have access.
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 addresses the attack surface, CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Contractor access must end when the job ends, or stale access persists. |
| NHI-05 — Overprivileged NHI | Per-job access should minimise contractor privilege to the task scope. | |
| NHI-07 — Long-Lived Secrets | Standing contractor access often relies on credentials that outlive the work window. | |
| Recommendation — Enforce offboarding to revoke contractor access as soon as the job closes. Scope contractor entitlements to the minimum access needed for each job. Replace long-lived contractor credentials with short-lived, job-bound access. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Contractor access depends on sponsorship, expiry, and access review governance. |
| Recommendation — Apply IAM controls to time-box contractor access and review it regularly. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Contractor accounts need lifecycle control, expiry, and timely disabling. |
| AC-6 — Least Privilege | Job-bound access should restrict contractors to only the permissions needed. | |
| IA-5 — Authenticator Management | Time-bound contractor access depends on controlled credential issuance and revocation. | |
| Recommendation — Disable contractor accounts when the job ends and document account lifecycle actions. Grant only the permissions required for the current maintenance task. Rotate or revoke contractor authenticators when access is no longer required. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Contractor access requires governed identity lifecycle and ownership. |
| A.5.18 — Access rights | Per-job contractor access is fundamentally about granting and removing access rights. | |
| Recommendation — Manage contractor identities with clear ownership, expiry and review. Review and remove contractor access rights when the job closes. | ||
Practitioner Guidance
What to verify: Confirm that every contractor entitlement has a named sponsor, a defined job scope, and an expiry date that is shorter than or equal to the work window. If any of those three are missing, the access is not job-bound in practice, even if it is labelled as temporary.
Common mistake: Treating “temporary” as a description rather than an enforced control. A temporary account that is renewed indefinitely is operationally persistent access, and it should be governed that way.
Decision rule: If the contractor must return for recurring work, reuse a pre-approved access pattern with fresh activation each time; if the work is unpredictable or sensitive, require explicit re-approval rather than leaving access standing.
Practitioner takeaway: The right question is not whether contractor access is convenient to keep, but whether the organisation can justify carrying the exposure between jobs when the work itself is intermittent.