Security-Related Application Conditions (SecRAC)

When a supplier designs a component or system to a target security level, some threats are handled inside the product and others are deliberately left to the environment. For instance, a controller might assume it sits in a physically protected cabinet, that its maintenance interface is reachable only through a monitored jump host, or that certain network flows are blocked by the operator's firewall. Each such assumption is written down as a SecRAC.

SecRACs are delivered with the security case and flow up the supply chain: a component supplier exports them to the system integrator, who either fulfils them, passes them on to the operator or documents why they do not apply. The operator must then implement and maintain them throughout the operational phase, and verify them during acceptance and periodic reviews.

SecRACs make explicit what is otherwise an unspoken gap: a product certified to SL 3 provides SL 3 only if its environment matches what the supplier assumed. Many real-world weaknesses in rail OT are not product flaws but unfulfilled application conditions, such as a maintenance port left reachable from a wider network.

For operators, SecRACs turn into concrete, auditable obligations. Demonstrating that they are met over years of operation, across upgrades and contractor changes, requires ongoing visibility into network flows, access paths and asset configuration rather than a one-time check at commissioning.