Without formal onboarding and offboarding, vendor accounts and access paths tend to stay active longer than intended. That creates lingering entry points, weak accountability, and extra work when regulators ask for proof of control. It also makes it harder to prove who had access, when access ended, and whether the right sessions were disabled on time.
What fails first when vendor onboarding and offboarding are informal?
The first break is usually control over access duration. If vendor accounts are created ad hoc and removed by email or memory, access tends to outlive the business need, which turns a temporary relationship into standing exposure. That also weakens accountability, because no one can confidently show who approved access, who owns it, or when it should end.
Utilities are especially sensitive to this because third parties often connect to operational systems, plant support tools, monitoring platforms, or regulated business processes. When onboarding is informal, the utility may never establish a clean baseline for scope, privilege, session handling, or evidence of approval, and that makes every later review harder to trust.
Formal onboarding also defines the boundary between a legitimate vendor relationship and an uncontrolled access path. Without it, the utility cannot reliably distinguish a current contract from an expired one, a supported system from a shadow integration, or a named user from a shared vendor credential. The result is not just administrative drift, but a control environment where access is difficult to inventory, recertify, or terminate on time.
Why does offboarding failure create such persistent exposure?
Offboarding is where weak process becomes visible. If a vendor relationship ends but accounts, tokens, VPN access, APIs, or remote support channels are not disabled in a coordinated way, the utility may still have active entry points that no longer have a legitimate business owner. That creates orphaned access, stale privileges, and an evidence gap when someone asks whether the termination actually happened.
In practice, this is the point where accountability and technical control need to meet. A vendor exit should trigger deprovisioning, privilege removal, session revocation, and record closure as one chain of actions. If those steps are split across procurement, operations, and security without a formal workflow, one or more access paths often survive the offboarding event.
Utilities also face a reconciliation problem. If the vendor access register, the system logs, and the contract status do not line up, the organisation may know a vendor is no longer engaged but still fail to prove that access was ended everywhere it mattered. That is exactly the kind of gap that turns into audit findings, delayed remediation, and preventable exposure.
What does this mean for governance, evidence, and third-party control?
Formal controls are not only about stopping misuse, they are also about proving control. In vendor-heavy environments, governance breaks down when the utility cannot demonstrate approval, scope, review cadence, and removal history with a single coherent trail. That matters because regulators and auditors usually care less about intent than about whether the utility can produce complete, timely evidence.
For a utility, the practical issue is whether vendor access is governed as a lifecycle, not as a one-time exception. Strong onboarding and offboarding require ownership, periodic review, and a definitive end state for every account or access path. Without that lifecycle discipline, access reviews become retrospective guesswork instead of reliable governance.
That is why third-party access is often the first place where identity governance, contract management, and operational security need to be aligned. A vendor can be legitimate, necessary, and still too broad, too long-lived, or too hard to verify if the onboarding and offboarding process is not enforced consistently.
Risk and Threat Considerations
Informal vendor lifecycle control creates persistent exposure because access can remain valid after the business relationship changes, the support need ends, or a named vendor contact leaves. In utility environments, that can leave remote entry points and privileged support paths open longer than intended, which raises both insider-style misuse risk and external compromise risk if vendor credentials are stolen or reused.
Failure mechanism: Accounts, credentials, and remote access paths are not tied to a formal approval, review, and revocation workflow, so deprovisioning is delayed, incomplete, or never verified end to end.
Impact: The utility loses confidence in who can still reach critical systems, exposed access can survive contract termination, and audit or regulatory requests become harder to satisfy with reliable evidence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Vendor onboarding and offboarding hinge on cloud identity governance and access lifecycle control. |
| Recommendation — Enforce IAM lifecycle controls for third-party access and verify timely deprovisioning. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Vendor accounts must be provisioned, reviewed, disabled, and removed through formal account governance. |
| IA-5 — Authenticator Management | Offboarding must revoke or rotate authenticators, tokens, and other access material used by vendors. | |
| AC-6 — Least Privilege | Informal onboarding often leaves vendors with excess permissions beyond the business need. | |
| Recommendation — Apply AC-2 to approve, track, review, and disable vendor accounts on schedule. Use IA-5 to manage and revoke vendor authenticators and credential material promptly. Restrict vendor access to least privilege and remove excess rights at offboarding. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Vendor access needs formal approval, restriction, and removal under access control governance. |
| Recommendation — Implement access control rules that define vendor approval, scope, and revocation. | ||
Practitioner Guidance
What to prioritise: Treat vendor onboarding and offboarding as a lifecycle control with named ownership, not as a procurement or help desk task. The first priority is to ensure every vendor access path has a business owner, a technical owner, and a defined expiry or review date.
What to verify: Before trusting the control, verify that termination events actually remove access from all relevant layers, including application accounts, VPN or remote access, privileged entitlements, and active sessions. The useful test is not whether a ticket was closed, but whether access is no longer usable.
What good looks like: A utility should be able to produce a current vendor inventory, the approval trail for each active relationship, and evidence that offboarding closes accounts and sessions promptly when the relationship ends. If that evidence is fragmented, the process is not yet controlled enough for high-trust third-party access.
Practitioner takeaway: The real failure is not merely “forgotten accounts”, it is the absence of a lifecycle that proves access was justified when granted and actually removed when it was no longer needed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
