Accountability should sit with the identity owner and the application owner together, because one controls the lifecycle trigger and the other controls the actual entitlement. If a leaver still has access, the organisation needs a documented control that proves where the removal broke down, not just who submitted the workflow.
Why This Matters for Security Teams
Jira offboarding is not a paperwork issue. It is an identity governance failure that can leave tickets, service accounts, API tokens, and linked tools active after a user is meant to be removed. In practice, the question is not whether a workflow was submitted, but whether the entitlement was actually revoked across the systems that Jira touches. That is why accountability must be shared between the identity owner and the application owner, with evidence at each control point.
Security teams often underestimate how much access can survive in collaboration tooling. The The 2025 State of NHIs and Secrets in Cybersecurity report from Entro Security found that 91% of former employee tokens remain active after offboarding, and that figure maps directly to the kind of residual access Jira can conceal. OWASP’s Non-Human Identity Top 10 is also relevant here because offboarding failures usually involve secrets, tokens, and machine-to-machine access rather than only human accounts.
In practice, many security teams discover the missing revocation only after a leaver has already retained access to downstream systems, rather than through intentional offboarding verification.
How It Works in Practice
Accountability should be built around the control chain, not the ticket alone. The identity owner is responsible for triggering lifecycle actions, but the application owner is responsible for ensuring the target system actually removes access, invalidates tokens, and closes any alternate paths such as API keys or linked integrations. If Jira is used as the offboarding system of record, the record should show who approved removal, when the identity was disabled, and whether every connected entitlement was confirmed as revoked.
A practical control pattern is to treat Jira as the orchestration layer and not the source of truth for access state. That means the offboarding workflow should include:
- Verified identity disablement in the authoritative directory or IdP
- Revocation of Jira sessions, API tokens, and app links
- Confirmation that service accounts or automation tied to the leaver are reassigned or retired
- Evidence that downstream SaaS, SCM, and chat integrations also completed removal
For organisations managing broader NHI exposure, the NHI Lifecycle Management Guide and the Top 10 NHI Issues both reinforce the same operational point: lifecycle controls fail when ownership is split but validation is not. Current guidance suggests pairing offboarding with automated evidence collection, because manual sign-off alone cannot prove that every entitlement was actually removed. These controls tend to break down in heavily integrated Jira environments because app ownership is fragmented across teams and token issuance is handled outside the ticketing workflow.
Common Variations and Edge Cases
Tighter offboarding often increases operational overhead, requiring organisations to balance faster removal against integration complexity. That tradeoff becomes real when Jira is connected to dozens of SaaS tools, custom plugins, and automations that were never documented as part of the access model. In those environments, no universal standard exists for who owns every downstream entitlement, so the safest approach is to define ownership by control domain: identity lifecycle, application entitlement, and integration revocation.
There are a few common edge cases. Shared admin accounts can make it unclear whether a leaver ever had direct access or inherited access through a group. Automated agents or service accounts may still function after a human user is removed, which means the offboarding process must distinguish human identity from NHI and workload identity. Where Jira is used to track remediation, the workflow should require proof from the target system, not just closure in the ticket. That is especially important when secrets are embedded in Jira comments, attachments, or linked requests, because the access path can survive even if the named user is gone.
Best practice is evolving toward explicit evidence of revocation and periodic post-offboarding validation, not just a completed checklist. Organisations that want a broader control model can compare this issue with the 52 NHI Breaches Analysis, which shows how lifecycle failures often combine with exposed credentials. If the leaver’s access was granted through an integration token or shared automation path, the breakdown usually sits with the application owner’s revocation step, not the HR trigger itself.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Offboarding failures often leave secrets and tokens active after user exit. |
| NIST CSF 2.0 | PR.AC-4 | Access removal depends on enforcing least privilege and timely deprovisioning. |
| NIST AI RMF | GOVERN | Accountability needs documented ownership, evidence, and oversight across lifecycle steps. |
Assign named owners for identity and application revocation, then track proof of completion.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
