This week, three different security decisions expose the risk between the current state and the intended control.
Renfe and Adif need incident evidence that can support containment and restoration across organisational boundaries. CODESYS CVE-2026-79625 requires a product-specific assessment of authenticated monitoring, concurrent access and workable temporary controls. Monta's response to OCPP station-identity weaknesses requires authentication support to become enforced configuration across a mixed fleet without breaking charging service. These cases are not equivalent. Together they show that a security target becomes defensible only when the move toward it has a known starting state, accountable owner, acceptance evidence and supported recovery path.
The pattern this week
The control is not complete until the transition can be operated and reversed safely.
Renfe and AdifIncident scope evolvingEach material finding must reach an owned containment or restoration decision across organisations.
→
CODESYS monitoringRemediation identifiedThe deployed runtime, client authority, concurrency and required plant functions determine a workable change.
→
Monta OCPPAuthenticated profile supportedFleet migration still needs enforced credentials, compatibility tests and recovery evidence.
Common gap: a target state describes intent. The operating decision lives in the controlled transition, its acceptance evidence and the path back when validation fails.
Renfe and Adif: make evolving evidence usable across organisational boundaries.
Renfe and Adif published separate notices describing possible data exposure while their investigations continued. Those notices do not establish one technical attack chain, access to signalling or physical harm. The operational challenge is to keep uncertainty visible while different organisations make connected decisions. A shared, versioned incident record should identify the affected service, evidence source, collection time and confidence, then link each material finding to an accountable containment or restoration decision. A broad disconnection can remove required services without resolving the relevant authority. Restoration needs its own acceptance evidence covering the recovered function, credentials, delegated permissions and supplier access that remain trusted.
DecisionUse one versioned evidence record to connect each confirmed, suspected or unresolved finding to an owned decision and reassessment trigger, without inventing a common attack chain.
OT & ICS · PLC Runtime Security · Change Assurance
CODESYS: remediation has to preserve the plant function it is meant to protect.
CVE-2026-79625 concerns improper synchronisation in CmpMonitor2 when authenticated monitoring access and concurrent requests are present. The advisory describes incorrect data processing or denial of service; it does not demonstrate exploitation in a plant or a physical safety consequence. Applicability depends on the product, deployed runtime, configuration and simultaneous client access. A temporary restriction therefore needs to name the identity or route being limited and the required HMI, engineering or support function that must remain available. On 22 October, CERT@VDE updated the advisory to state that fixed SL runtimes are now available: 3.5.22.40 for the affected 3.x products and 4.23.0.0 for the listed SL products. Availability narrows the remediation choice, but it does not identify the installed product or prove that the update has been validated against the plant's required functions. Validation should cover the targeted security condition, required communications and process behaviour, with recovery agreed before the production change.
DecisionAssess monitoring authority and concurrency against the deployed runtime, then validate a supported restriction or update with operational acceptance and recovery criteria.
Monta: support for authenticated OCPP is not evidence of fleet enforcement.
CISA's advisory describes missing WebSocket authentication that can permit station impersonation. It reports Monta support for OCPP 1.6 Security Profile 2 and a rolling transition away from unauthenticated connections, while reporting no known public exploitation specifically targeting the listed vulnerabilities at the review date. Migration should connect station model, firmware, configured profile and support ownership. Acceptance needs both negative and positive tests: a connection presenting a valid station identifier without the corresponding credential should be rejected, while the legitimate station should connect and recover. Unsupported units need a bounded exception, restricted exposure and an owned upgrade or replacement path. Encryption protects the channel; it does not by itself prove the identity authorised to use it.
DecisionClose the migration only when deployed endpoints enforce station identity and operations can provision, revoke and recover legitimate access under a supported procedure.
Could the change owner prove the starting state, acceptance result and recovery path without relying on the person who performed the change?
Choose one cross-organisation restriction, runtime update or authentication migration. Record the exact starting configuration, accountable owner, function that must remain available, positive and negative acceptance evidence, stopping condition and supported recovery procedure. Then ask another responsible person to reconstruct why the transition was safe enough to approve. If the evidence only describes the intended end state, the control remains incomplete.
