They break down when the identity process follows employment status only and ignores the project lifecycle. In construction, staff, contractors, and partner users may need access for a short period and then lose it quickly. If removal depends on manual follow-up, access outlives the work it was granted for.
Why Project-Based Teams Need a Lifecycle, Not Just a Hire-and-Fire Process
onboarding and offboarding fail when organisations treat access as a one-time employment event instead of a time-bound work assignment. Project-based environments add changing sponsors, short engagements, subcontractors, and external partners, so the control point has to be the project lifecycle. When that lifecycle is not the source of truth, access is granted too broadly, too early, or left behind too long.
The practical problem is that project work rarely maps cleanly to HR status. A person can move from planning to build to support in weeks, and each phase may need different systems, environments, and approvals. That means the identity process must understand role, project, and end date together, not just the fact that someone is employed or not.
In construction and similar delivery-heavy environments, the access question is often, “What is this person allowed to do on this project right now?” not “Are they still on payroll?” That distinction matters because project access may need to start before day one for mobilisation and end immediately after a handover, especially where site systems, drawings, schedules, or partner portals are involved.
Where Manual Follow-Up Breaks the Model
The failure usually appears in the handoff between project managers, HR, and system owners. If no one owns the joiner, mover, and leaver workflow end to end, onboarding becomes ad hoc and offboarding depends on someone remembering to send a ticket, chase approval, or confirm completion. The result is stale access, orphaned accounts, and lingering permissions that no longer match the work.
This gets worse when the organisation uses shared drive access, vendor portals, temporary credentials, or delegated approvals for project teams. Those controls can be efficient, but they also hide who should revoke access when the project closes. The more the project relies on exceptions, the easier it is for expired access to survive through the next phase or the next engagement.
Joiner-Mover-Leaver (JML) Guide is a useful reference for this model because it treats onboarding and offboarding as a lifecycle process rather than a static HR event. For broader identity governance context, IAM and IGA Basics explains how provisioning, access review, and entitlement management support controlled access over time.
What Good Lifecycle Control Looks Like in Project Work
Good practice is to bind access to an authoritative project record with a clear start, sponsor, scope, and end date. That record should drive provisioning, role changes, periodic review, and automatic deprovisioning, so removal does not depend on memory or manual cleanup. Where partners and contractors are involved, the project sponsor should also be accountable for confirming when access should stop.
Effective controls also separate short-lived project access from standing access. If a user needs the same permissions across multiple projects, the organisation should still recertify those permissions against the active assignment, not preserve them because they were once approved. That reduces privilege creep and prevents temporary access from becoming the default.
NHI Lifecycle Management Guide is relevant here because the same lifecycle discipline applies to non-human and temporary project access, especially where credentials and entitlements have their own expiry and rotation requirements. The underlying rule is consistent: the access lifecycle should end when the work ends.
Risk and Threat Considerations
When onboarding and offboarding lag the project lifecycle, access accumulates beyond the point of need. That creates exposure from stale accounts, overprivileged project access, and delayed revocation, all of which widen the window for misuse after a role change, a project closeout, or a contractor exit.
Failure mechanism: project access is granted through informal approvals or manual tickets, then never removed because no lifecycle owner is responsible for closing it when the assignment ends.
Impact: former project participants can retain entry to systems, documents, environments, or partner portals, which increases the chance of unauthorized access, accidental changes, or credential misuse after the work has finished.
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 CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Project access depends on timely credential lifecycle control and revocation. |
| AC-2 — Account Management | Onboarding and offboarding failures are account lifecycle failures in project teams. | |
| AC-6 — Least Privilege | Project work often creates overbroad temporary access that should be minimized. | |
| Recommendation — Enforce time-bounded credential lifecycle and revoke access at project closeout. Bind accounts to project assignment and disable them when the assignment ends. Limit project users to the minimum permissions needed for the current phase. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The issue is lifecycle-driven access governance for changing project assignments. |
| Recommendation — Tie provisioning and deprovisioning to authoritative project ownership and end dates. | ||
| CIS Controls v8 | 5 — Account Management | Project onboarding and offboarding are fundamentally account and entitlement control problems. |
| Recommendation — Maintain current account inventories and remove access promptly at project completion. | ||
Practitioner Guidance
What to prioritise: make the project record, not the employment record, the driver for time-bound access decisions. If a user is attached to a project, the project should define the access start, review point, and stop date.
What to verify: confirm that every project has an accountable sponsor and that every elevated entitlement has a named removal trigger. If a user can still reach a system after the project has ended, the control has failed even if the account technically still exists.
Common mistake: treating contractor offboarding as a one-time checklist item. In project-based environments, offboarding is a lifecycle event that must be tied to delivery milestones, handover, and sponsor sign-off.
Practitioner takeaway: the best indicator of control quality is whether access disappears automatically when the work does, because manual cleanup is too slow for short-duration project teams.
Related resources from NHI Mgmt Group
- Why do perimeter-based trust models break down in Kubernetes environments?
- Why do playbook-based SOC workflows break down in multi-tenant environments?
- Why do ticket-based workflows break down when DSPM findings grow across cloud and SaaS environments?
- How should security teams implement group-based access control in environments with frequent onboarding and offboarding changes?