Yes, where code and identity controls intersect. Secret handling, authentication, authorisation, and access policy defects often originate in the same development workflow that generates broader AppSec debt. A shared remediation model avoids duplicate queues, makes prioritisation clearer, and reduces the chance that identity-sensitive flaws sit unaddressed behind generic code issues.
Why a shared backlog makes sense when application and identity defects are intertwined
AppSec backlog and identity governance should be treated as one programme when the same delivery path creates both code defects and access defects. Authentication, authorisation, secrets handling, and entitlement logic are often implemented together, reviewed by the same teams, and broken by the same release. A single programme gives one prioritisation model, one ownership view, and one remediation cadence.
That is especially true when identity issues are not just policy questions but product defects: broken auth flows, weak token handling, missing access checks, and insecure secret storage. Those issues belong in the same remediation conversation as the rest of the application backlog because they change exploitability, not just compliance posture. Practical guidance from OWASP ASVS and OWASP SAMM supports that shared treatment.
A useful test is whether the defect can be fixed only by changing code, or whether the fix also needs access policy, role design, review, or secret rotation. If both are required, splitting the queues usually slows the work and hides the real blast radius. A shared programme makes the dependency visible before the issue becomes either a production incident or a failed audit finding.
Where the boundary still matters
One programme does not mean one undifferentiated queue. Code-level flaws and governance-level findings still need different triage signals, owners, and SLAs. A missing authorisation check in an API, for example, is a software defect; an unused privileged role that has never been recertified is an access governance defect. They can sit under the same programme while still being routed to the right resolver group.
The practical value comes from a common risk language. Identity-related backlog items should be ranked by the same factors as other AppSec work: reachability, privilege, exposure path, compensating controls, and likelihood of abuse. That prevents teams from treating access review debt as lower priority simply because it does not look like a classic vulnerability.
Shared treatment also helps when the issue crosses delivery and operations. If a sprint introduces a new service account, token, or role, the backlog item should cover creation, restriction, and retirement together. Otherwise teams fix the code path but leave standing access, stale secrets, or excessive permissions behind. Reference material such as the IAM and IGA Basics guide and the NHI lifecycle management section are useful here because they frame identity as a lifecycle problem, not just a control checkbox.
How to organise the work without creating a governance swamp
Use one programme, but keep distinct work types inside it. A good operating model usually has three lanes: product security defects, identity governance actions, and joint remediation items that need both code and access changes. That structure preserves clarity without forcing separate planning, separate reporting, or separate prioritisation boards.
Teams should also make remediation close the loop. A code fix is not complete if it still leaves a broad permission, a long-lived secret, or an orphaned account in place. Likewise, an access cleanup is not complete if the application design still allows weak authentication or broken function-level controls. The Access Reviews and Certification Guide and the Segregation of Duties Guide are good examples of how to connect review, entitlement, and control design in one remediation flow.
Where organisations struggle is ownership. AppSec teams often own the finding, while IAM or GRC teams own the remediation mechanism. The programme should define who can change the code, who can change policy, and who confirms closure. Without that split, defects bounce between queues and identity-sensitive issues stay unresolved longer than ordinary code flaws.
Risk and Threat Considerations
When backlog management separates code defects from identity defects, attackers benefit from the gap. Weak authentication, over-privileged access, and exposed secrets often become the first step in privilege escalation or lateral movement, while generic app bugs can become far more dangerous once linked to a valid identity path. The risk is not only delay, but misclassification of the real attack surface.
Failure mechanism: A team remediates the software flaw but leaves the surrounding identity control untouched, or fixes the identity policy while the application still allows the same misuse path. That creates residual exposure through stale credentials, excessive permissions, broken access checks, or unreviewed service accounts.
Impact: The organisation gets a false sense of closure, while the attacker still has a viable path to data, functionality, or privilege. Over time, the backlog can accumulate unresolved high-impact items that look operationally separate but are actually one exploit chain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, OWASP SAMM and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | Shared backlog items often include auth defects that shape exploitability. |
| V8 — Authorization | Access-check flaws and privilege errors are central to joint AppSec and identity remediation. | |
| Recommendation — Verify authentication requirements alongside code fixes for identity-sensitive defects. Enforce authorization checks as part of the same remediation workflow. | ||
| OWASP SAMM | g1 — Strategy & Metrics | One programme needs shared prioritisation, ownership, and measurement across AppSec and identity work. |
| Recommendation — Align security metrics and ownership across application and identity remediation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Secret handling and credential lifecycle defects are part of the shared backlog question. |
| AC-6 — Least Privilege | Over-privilege and access-policy defects are a core reason to unify remediation. | |
| Recommendation — Manage authenticator lifecycle changes within the joint remediation process. Apply least-privilege controls to reduce identity-related backlog risk. | ||
Practitioner Guidance
What to prioritise: Put any backlog item into the shared programme when the defect can affect authentication, authorisation, secrets, roles, or account lifecycle. If the issue changes who can reach a function or what they can do, it belongs in the joint queue.
Decision rule: If fixing the defect requires both code change and access change, treat it as a single remediation item with one owner and one due date. If only one side changes, keep it in the shared programme but route it to the specialist team responsible for execution.
What good looks like: The programme can show one prioritised list, one closure definition, and one reporting view for defects that span software and identity controls. That is the clearest sign the organisation is managing the actual risk rather than the organisational silo.
Practitioner takeaway: Treat the backlog as one programme when the exploit path is one programme. Separate the teams, not the risk.
Related resources from NHI Mgmt Group
- What breaks when organisations treat identity compliance as a one-time legal exercise instead of an ongoing governance function?
- Should organisations treat AI agent governance as a one-time rollout or an ongoing programme?
- Should organisations treat HIPAA compliance and identity governance as the same programme?
- Why is it important to integrate identity and data governance?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org