EU CRA and AI security accountability are converging in 2026

At a glance

What this is: Kusari says 2026 will force software teams to treat open source risk and AI-produced code as accountable governance issues, not informal engineering preferences.

Why it matters: For IAM, PAM, and NHI practitioners, the identity-relevant shift is that software supply chain controls now need ownership, review, and policy enforcement across human and AI-assisted workflows.

Context

The core problem is not that organisations lack policies. It is that software delivery, open source reuse, and AI-assisted development often outrun the ability to assign clear ownership, verify provenance, and enforce consistent controls. In practice, that creates a governance gap where risk is inherited faster than it is understood, which is why contextual visibility matters more than static inventory.

The article connects that gap to two converging pressures: the EU Cyber Resilience Act and the growing expectation that AI-generated output must sit inside normal security and accountability processes. That intersects with identity governance because code, tooling, and AI systems all act through credentials, permissions, and approvals; if those are not controlled, software risk becomes a privilege and accountability problem as much as a development problem.

Kusari frames standardisation as a way to reduce variance across teams rather than a constraint on delivery. That is a typical challenge in modern software organisations, not an edge case.

Key questions

Q: What breaks when open source risk is treated as someone else’s responsibility?

A: Accountability breaks first. If teams assume upstream developers or package maintainers own the risk, they usually miss the internal controls needed to assess exposure, track remediation, and prove due diligence. The result is a gap between what is shipped and what can be defended under regulation, customer scrutiny, or insurance review.

Q: When should organisations prioritise contextual dependency analysis over SBOM-only compliance?

A: They should prioritise it whenever products ship into regulated markets, reuse transitive dependencies, or rely on software that may expose reachable attack paths. SBOMs help with inventory, but contextual analysis is what tells you whether a component is merely present or actually dangerous in the deployed environment.

Q: What do security teams get wrong about AI-generated code risk?

A: They often focus on catching insecure output after code is written, which is too late for AI-native workflows. The more important control point is the moment the agent is allowed to initiate the action. If that step is not governed, testing becomes a detection layer rather than a prevention layer.

Q: Which control model best fits open source and AI accountability in software delivery?

A: A shared control model works best when it ties ownership, review, and evidence together. Teams need consistent standards across development groups so that third-party code, AI-assisted output, and release decisions can all be traced to accountable owners and defensible security checks.

Technical breakdown

Why SBOMs do not create enough context

A software bill of materials lists components, but it does not explain how those components interact, which paths are reachable, or which dependencies create real exposure. That matters because vulnerability accountability depends on operational context, not component presence alone. In a modern supply chain, the security question is not only what is included, but what can actually be executed, inherited, or abused across build and runtime boundaries. Without that context, teams can prove inventory while still missing exploitable risk.

Practical implication: Practitioners need dependency context and reachability analysis, not component lists alone.

How open source accountability changes under the CRA

The CRA shifts open source from an informal upstream dependency model to a governed responsibility model for vendors selling into the EU. That means organisations cannot treat third-party code as someone else’s problem once it is embedded in a shipped product. Security expectations now extend to how software is selected, assessed, and maintained over time, which creates a direct link between supply chain governance and product accountability. The practical effect is that visibility, ownership, and remediation processes have to be defensible.

Practical implication: Map third-party code ownership to a clear internal control owner before release.

Why AI-produced code needs policy, not exception handling

LLMs are not a separate class of software that sits outside normal governance. They are software actors operating inside the same environment as human engineers, which means they must obey the same access rules, approvals, and review steps. The article’s key point is that AI becomes manageable when it is constrained by organisational policy, trusted facts, and business context. That is especially important when generated output can influence code, architecture, or security decisions without a human noticing the change in risk posture.

Practical implication: Treat AI-assisted development as a governed workflow with review and authorisation checkpoints.

Threat narrative

Attacker objective: The objective is to exploit weak software governance so that risky code ships with insufficient oversight, accountability, or remediation traceability.

1. Entry begins when unreviewed open source or AI-generated code enters the software delivery pipeline without enough context to show what it can reach or affect.
2. Escalation follows when inherited dependencies, overly broad permissions, or ungoverned AI output amplify the impact of that code inside the product or build environment.
3. Impact occurs when the organisation cannot prove accountability for the resulting vulnerability, exposure, or control failure and is left to absorb regulatory, insurance, or customer consequences.

Breaches seen in the wild

• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Accountability is becoming the operating model for software supply chain risk. The article captures a wider shift from advisory security language to enforceable responsibility. When software products include open source and AI-assisted output, governance has to prove who owns the risk, who reviews it, and who can remediate it. For practitioners, this means moving beyond policy statements toward auditable control ownership.

Context is now the missing control in software inventory programmes. SBOMs are necessary, but they are not sufficient because they do not explain reachability, inheritance, or business impact. That leaves teams with visibility into components but not into exposure. The named concept here is contextual supply chain visibility, and it is becoming the difference between compliance theatre and actionable control.

AI-generated code should be governed like any other privileged software input. The article is right to frame LLMs as software actors that must stay inside policy, approvals, and least-privilege constraints. In identity terms, that means the workflow around the model matters as much as the model itself. Practitioners should treat AI-assisted development as a controlled production path, not a side channel.

Standardisation is emerging as a security and delivery control, not a paperwork exercise. The operational lesson is that consistent baselines reduce variance, and variance is where accountability breaks down. That aligns with the broader move toward measurable governance in software programmes, where shared controls make it easier to prove compliance and recover faster. The practitioner implication is to standardise control expectations before scaling delivery.

Insurance and regulation are converging on the same question: can you prove control, not just intent? The article shows why the market is moving away from trust in developer good faith toward evidence of constrained behaviour. That has implications for software suppliers, platform teams, and security leaders alike. The practitioner conclusion is to prepare for accountability reviews that ask for proof, not promises.

From our research library:

• Software supply chain attacks were projected to cost organisations $60 billion in 2025.

What this signals

Contextual supply chain visibility: this is the shift that matters most for practitioners, because component inventories without reachability and transitive relationship data cannot support real accountability. The practical implication is that release governance must move closer to risk-based evidence and away from static artefact lists.

The identity bridge here is operational, not theoretical. AI-assisted development, open source reuse, and release approvals all depend on permissions, review authority, and traceable decision rights, so software supply chain governance now intersects with IAM, PAM, and NHI control ownership.

Teams that keep treating AI-generated code as a novelty will struggle to meet the coming bar for evidence. The better programme design is to make policy enforcement and human approval visible at the same point where code enters the delivery pipeline.

For practitioners

• Define a named owner for third-party code risk Assign accountability for open source risk to a specific product or platform owner, with a clear path for vulnerability triage, approval, and remediation.
• Replace SBOM-only reviews with contextual dependency analysis Add reachability, dependency relationships, and transitive exposure to your release review so component inventory becomes decision-ready context.
• Apply the same review gates to AI-generated code Require policy checks, human approval, and traceable justification before AI-produced output can move into build or release workflows.
• Standardise secure baseline controls across delivery teams Use a shared minimum control set so teams do not invent incompatible security practices that make governance and response harder to evidence.

Key takeaways

• Open source and AI-produced code now sit inside a broader accountability model, not a best-effort engineering culture.
• SBOMs remain useful for inventory, but they do not explain reachability, dependency inheritance, or real exposure.
• The practical response is to combine ownership, standardised controls, and policy-enforced review across human and AI-assisted workflows.

Key terms

• Contextual Supply Chain Visibility: The ability to see not just which software components exist, but how they relate, what they can reach, and where inherited risk actually lands. It is the difference between an inventory record and a decision-grade view of exposure across build and runtime.
• Software Supply Chain Accountability: Software supply chain accountability is the obligation to know who built, changed, approved, and delivered software components. It requires traceability across code, dependencies, build systems, signing, and deployment. In practice, it links artifacts to responsible identities, preserves evidence, and supports audit, incident response, and trust decisions across the software lifecycle.
• AI-Assisted Governance: AI-assisted governance uses machine analysis to speed up identity work such as summarising access, grouping users, or drafting queries. The human remains responsible for policy, approval, and remediation, so the model augments governance rather than becoming the decision-maker.
• Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle controls. It helps practitioners connect accountability, access control, and operational governance across modern security programmes.