EU CRA and AI security accountability are converging in 2026

At a glance

What this is: This is a governance analysis of how the EU Cyber Resilience Act, open source accountability, and AI security are converging into a single operational problem for software teams.

Why it matters: It matters because identity, access, and approval controls now sit inside broader software supply chain governance, especially where AI systems and third-party code can create unreviewed risk.

👉 Read Kusari's analysis of CRA, open source accountability, and AI security

Context

The core problem is no longer whether software teams can write secure code in theory. The issue is whether organisations can prove accountability for third-party code, AI-generated output, and the controls that govern both across the software lifecycle. The EU Cyber Resilience Act pushes that accountability from guidance into enforceable obligation, while AI security is being pulled toward the same discipline.

For identity and access practitioners, the intersection is real wherever code, models, and pipelines depend on secrets, approvals, and scoped access. The article is strongest when it treats AI systems as constrained actors inside existing policy boundaries, which is the right direction for governance even if the broader cloud and supply chain framing is not identity-specific. That starting position is increasingly becoming the norm rather than the exception.

Key questions

Q: How should security teams govern AI-generated code in production environments?

A: Security teams should treat AI-generated code as normal production code with extra provenance risk. Require architectural review, test coverage, static analysis, and approval before merge. Then bind the agent and the build pipeline to least privilege, short-lived credentials, and complete audit logging so implementation speed does not outrun control.

Q: Why are SBOMs not enough to secure the software supply chain?

A: SBOMs improve visibility into what is inside a package, but they do not prove who built it or whether the build was tampered with. That is why provenance, signing, and policy enforcement matter. Without those controls, teams can document composition while still shipping untrusted software into production.

Q: What do teams get wrong about AI security and access management?

A: Teams often treat AI security as a data classification problem alone. In practice, the larger risk is over-privileged machine identity, because an agent with broad credentials can move through systems faster than human review cycles can respond. Effective governance requires both identity control and data control.

Q: Which controls matter most for reducing exposure across software supply chains?

A: The most effective controls combine accurate inventory, rapid containment, validated remediation and ownership for every critical dependency. Teams should also map which non-human identities and secrets are tied to vulnerable applications, because exploit impact is often driven by what the software can reach, not just by the code defect itself.

Technical breakdown

Why SBOMs are not enough for software accountability

An SBOM lists components, but it does not explain how those components interact, which dependencies are reachable, or where risk becomes actionable. That distinction matters because regulatory accountability is about more than inventory. It requires contextual understanding of transitive exposure, exploitability, and whether a vulnerability can actually affect a shipped product. In practice, teams need dependency graphs, reachability analysis, and policy-backed triage to turn visibility into control. Without that layer, organisations can claim they know what is in the build while still missing the paths that create real exposure.

Practical implication: pair inventory with reachability and risk context, or you will keep discovering obligations after release.

How OSPS-style baselines reduce delivery friction

A shared secure development baseline works because it narrows variation across teams before that variation becomes compliance debt. Open Source Project Security Baseline style controls create a common minimum for checks, reviews, and escalation, which makes security repeatable rather than ad hoc. The technical value is not abstraction, but standardisation of evidence, policy, and workflow. That gives engineering and security teams a common operating model, so the controls can be automated earlier and measured consistently across products and repositories.

Practical implication: standardise secure development controls across teams before compliance evidence becomes fragmented and expensive.

Least privilege for AI systems and the identity boundary

The article’s AI point is strongest when LLMs are treated as software components that operate within policy, not as exceptions to policy. That means access should be bounded, approvals should be explicit, and AI-assisted actions should be attributable to human owners or controlled service identities. This is where the identity boundary matters: AI systems can generate output, but the credentials, permissions, and audit trail still belong to the programme that deploys them. Governance fails when teams allow model output to outrun identity controls.

Practical implication: bind AI workflows to scoped identities, explicit approvals, and auditable ownership.

NHI Mgmt Group analysis

Software accountability is becoming an identity problem as much as a compliance problem. Once AI-generated code, third-party libraries, and automated pipelines can all introduce change, the real control point becomes who or what is authorised to alter the system. That shifts attention from static policy documents to governed identities, approvals, and traceable execution paths. Practitioners should treat software supply chain accountability as a privilege and identity governance issue, not just a build-time assurance task.

SBOM-first thinking creates a visibility trap when organisations need decision-grade context. Component lists help inventory, but they do not tell you whether a dependency is reachable, exploitable, or operationally relevant. This is the governance gap the article exposes: visibility without context delays action. The practical lesson is to tie software inventory to risk prioritisation and ownership so that evidence supports decisions, not just audits.

AI governance debt is now accumulating inside ordinary software delivery. The article is right that LLMs will be treated more like constrained software actors than magical exceptions, and that is where governance will harden. The named concept here is AI governance debt: the backlog created when teams adopt AI capabilities faster than they define accountability, approval, and audit boundaries. Practitioners should close that gap before AI-driven code generation becomes an unmanaged control surface.

Insurance pressure is acting as an external control accelerator. Underwriting demands often move faster than internal governance programmes, which means security evidence requirements will arrive before some teams are ready. That does not change the underlying risk, but it does change the pace at which governance must mature. For practitioners, the message is to build evidence-producing controls now rather than retrofit them under deadline pressure.

Regulatory pressure will reward standardisation over bespoke security process design. When every team works differently, proving secure development and AI accountability becomes difficult to sustain. Standards like OSPS matter because they turn governance into repeatable operations across product lines. Practitioners should expect security maturity to be judged by consistency, not by intent.

What this signals

The governance signal for practitioners is that software accountability will increasingly be measured by evidence quality, not policy volume. Teams that can show ownership, approval history, and reachability context will be better placed to satisfy both regulatory and insurance scrutiny.

AI governance debt: if organisations keep adopting AI-assisted development before formalising approval and audit boundaries, they will accumulate hidden control gaps that become expensive to unwind later. That debt will show up first in exceptions, then in audit findings, and finally in slower delivery.

The practical response is to align delivery controls with identity controls, because the same identities that move code, secrets, and approvals are now part of the risk surface. Where possible, map those controls against NIST Cybersecurity Framework 2.0 so governance, detection, and recovery stay connected.

For practitioners

• Map software accountability to named owners Assign a human owner for every repository, pipeline, and AI-assisted workflow that can introduce code or configuration changes. The goal is to make approval, escalation, and audit responsibilities traceable before a defect or compliance question appears.
• Add reachability context to component inventories Move beyond SBOM-only reporting by adding dependency reachability, exposure paths, and exploitability context. This lets teams prioritise the libraries and transitive dependencies that can actually affect shipped products.
• Standardise minimum secure development controls Adopt a common baseline for code review, automated checks, secret handling, and escalation so every team produces comparable evidence. Consistent controls reduce compliance variance and make remediation repeatable across the portfolio.
• Bind AI workflows to scoped identities Require least-privilege access, explicit approvals, and logged attribution for AI systems that generate code or security recommendations. AI should operate as a controlled participant in the workflow, not as an unbounded source of changes.

Key takeaways

• The article’s central message is that software accountability is moving from policy statements to enforceable operational control.
• SBOMs, standards, and AI usage only become useful when organisations can show ownership, context, and approval boundaries.
• Teams that standardise evidence-producing controls now will be better prepared for regulation, insurance scrutiny, and AI-assisted delivery.

Key terms

• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.

What's in the full article

Kusari's full article covers the operational detail this post intentionally leaves for the source:

• Specific examples of how Kusari expects CRA accountability to affect software teams working with open source dependencies
• The practical shape of OSPS-aligned controls and how organisations are using them to reduce delivery variance
• The article’s broader view of AI security as a governed software discipline, including policy and review boundaries
• How insurance pressure is changing expectations for AI-driven products and accountable engineering

👉 Kusari's full article expands on the CRA, OSPS, and AI governance shifts shaping 2026.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity in a practical format. It helps practitioners connect identity controls to broader security and delivery programmes.