Session recap from Realize LIVE Europe 2026 in Amsterdam.
At Realize LIVE Europe in Amsterdam, Jiri Walek, Co-CEO of Nextedy, and Radek Krotil, Head of Products, presented “From TARA to Cybersecurity Case — Operationalizing and Scaling Product Cybersecurity in Polarion.” The starting point: R155/R156, ISO/SAE 21434, IEC 62443, NIS2, and CRA differ in scope, but they converge on one practical question — can you show how cybersecurity risk decisions connect to architecture, controls, requirements, verification, and residual risk, as the product changes?
In Brief
Cybersecurity evidence is becoming a lifecycle obligation. A TARA that does not follow the product as it changes turns into a snapshot of an older product.
Safety engineering already has the operating discipline this requires. The methods differ; the lifecycle discipline transfers.
In Polarion, the threat-to-evidence chain — threat, goal, control, requirement, test, residual risk — is authored in one sheet, and the cybersecurity case is generated from live data instead of reconstructed before an audit.
AI assists the analysis, grounded in existing project data, with the engineer keeping the final decision.
Watch the full session recording:
Most Requirements Are Born From Risk
When Radek asked a Realize LIVE audience last year how many of their requirements originate in risk, the room settled on 60 to 70 percent. That number frames the whole session: requirements management gets the attention, but a majority of requirements exist because a risk analysis said they should. And in a period when AI increasingly generates designs and code from requirements, the connection between risks and requirements becomes the foundation everything else builds on.
The Work Exists. The Evidence Chain Is Fragile.
Most teams already do the work: TARA, requirements, controls, and tests all exist. What fails is keeping them synchronized as the product changes. Three patterns come up repeatedly. Scoring drift: the same threat rated differently by different teams, making risk decisions hard to compare or defend. Stale analysis: the architecture moved on and the TARA did not fully follow. Late evidence reconstruction: the audit arrives, and the chain from threat to control to requirement to test is rebuilt by hand.
As the session put it: spreadsheets are not the enemy. Disconnected lifecycle evidence is.
Cybersecurity Can Borrow Safety’s Operating Discipline
Safety engineering solved a structurally similar problem years ago. Hazard corresponds to threat scenario, risk classification to impact and feasibility rating, safety goal to cybersecurity goal — and both disciplines end in requirements, verification, and a case. Not the same risks, and not the same methods, but the same lifecycle discipline. Teams that already run HARA and FMEA in a managed lifecycle can apply the identical operating model to TARA.
One Record for Safety and Cyber: the V2X Example
A V2X transceiver in a vehicle sits exactly on the safety–cyber boundary. The safety analysis sees a hazard: a false or missed collision warning. The threat analysis sees spoofed communication between peers. Handled in two disconnected systems, these remain two problems with two mitigations to reconcile. Handled on one engineering record, they share one control — PKI authentication is the cybersecurity control and the safety mechanism at the same time. One record, two cases. The alternative — connecting every discipline to every other — is a many-to-many integration mesh nobody wants to maintain.
Rows for Analysts, Records for Auditors
The working surface for all of this is Nextedy Risksheet: an Excel-familiar sheet where every row is a live chain of five or six Polarion work items, read naturally left to right — identify, assess, treat, control, verify. Analysts filter, sort, compare versions, and edit without leaving the engineering record. One medical risk sheet in production exposes fifty different work item types in a single interactive view — something a standard form-based interface cannot carry.
The tool does not prescribe the methodology; the template does. TARA, STRIDE, CVSS, HARA, FMEA — one engine, configured rather than coded, which also means an existing Excel-based method can usually be converted within days. Traceability stops being a separate activity: it grows while the table is filled in, as a by-product of normal engineering work.
The cybersecurity case itself lives on the system tree. Every node — vehicle, subsystem, ECU, function — carries its own analysis, and the case is a view of the architecture generated from live data, not a deliverable assembled at the end.
AI That Stays Governed
The AI assistance follows the same philosophy. Because the template defines what the data means — system elements, functions, threats, damage scenarios, controls — the assistant works with real context: find relevant threats, propose controls, check consistency, locate similar risks. Crucially, suggestions are grounded in data already in the project, each with an explanation of why it is relevant, rather than freely generated content. A small practical example from medical: searching for “air bubbles in blood” finds “gas embolism.”
The engineer keeps the review gate — accept, edit, or reject, with the decision stored in Polarion. AI does not decide, does not sign off, and does not replace the engineer. The efficiency case does not depend on AI either: Johnson & Johnson reports roughly 50 percent time saved on risk assessments with Risksheet — before any AI assistance.
Key Takeaways
Cybersecurity is lifecycle evidence. Not a TARA done once — evidence maintained as the product changes.
Risk is the integrator. Threats create controls, controls create requirements, requirements need verification.
The shared record matters. Without one record, every discipline becomes another integration project.
The case should be generated. A cybersecurity case should be read from maintained engineering data, not reconstructed before an audit.
AI must stay governed. AI can find gaps and reuse patterns. The engineer decides. Polarion remembers.
Try It Yourself: the 30-Day Trial
The session ran on the Nextedy cybersecurity solution, available as a free 30-day trial: an ADAS TARA reference template with system, subsystem, and component-level analysis, threats, controls, requirements, and tests pre-wired, the cybersecurity case generated from live Polarion data, and AI-assisted threat and control suggestions. A realistic goal, in the words of the session: one of your own TARAs running in Polarion within a week.
Want to discuss how this maps to your setup? Book a call with the team.