For a machine builder preparing equipment for the EU market from 20 January 2027, the working fix is a traceable control plan: identify the machinery scope, determine applicable requirements, and prove that unauthorized attempts to alter programmable safety logic are detected, recorded, and assigned to an operator. A logging feature alone does not establish that the machine meets its risk-based safety and security objectives.
Applicability register for each machine configuration
Regulation (EU) 2023/1230 replaces Machinery Directive 2006/42/EC and applies from 20 January 2027 to machinery within its scope. Use that date to plan the changeover, but evaluate each machine and configuration rather than assuming that a product family has one answer. Record which machines are placed on the EU market, their intended functions, safety architecture, and the party responsible for integration and commissioning. A machine delivered as a standalone unit can have different logging infrastructure from a complete plant where the builder supplies centralized monitoring.
Keep the scope record tied to the product’s technical file and configuration control. When a machine variant changes its programmable safety functions, access routes, or network connections, revisit the relevant risk and compliance decisions. This avoids treating a document prepared for one configuration as evidence for another. Use the regulation’s official text for the legal wording; use engineering records to show how each machine implements its selected controls.
- Check the applicability register against the machine order and market destination; the expected reading is a recorded scope decision for every configuration intended for the EU market from 20 January 2027.
Standards register linked to the machine risk assessment
Build the standards register from the machine’s hazards, safety architecture, and relevant security risks. The regulation is not a substitute for identifying the technical standards that apply to the equipment. A standards register should state the standard or requirement considered, the machine function it addresses, its edition or status, and the design or verification record that demonstrates how the requirement was handled. Do not copy a generic list from a seminar or treat a device supplier’s product training as a complete compliance method.
Contact the national standards body in the country where the work is being performed for standards education and help identifying relevant publications. Confirm the actual standards and their current applicability through authoritative standards and regulatory sources. Keep the rationale when a listed standard is not applicable; that makes the boundary of the assessment reviewable without accumulating unrelated paperwork. Training should improve the team’s ability to select and apply requirements, not merely demonstrate a product.
- Review the register for each machine family; the expected reading is a standards-to-requirements map with a recorded applicability rationale and a linked design or test record for each applicable item.
Asset and responsibility boundary around the safety PLC
Draw the machine boundary before selecting a logger. Identify every programmable asset that can affect safety or machine operation, including safety PLCs, other PLCs, engineering computers, HMIs, SCADA systems, and routers where they are part of the delivered installation. Record local programming ports, network paths, remote-access routes, and who controls each one. A machine that has no safety PLC is not automatically free of programmable safety functions or cybersecurity exposure; determine the actual architecture and the safety functions it implements.
Separate the machine builder’s deliverables from plant-wide services. A builder may provide an event-producing controller and integration documentation while the customer or a third party operates the log server and response process. That arrangement only works when the interfaces and responsibilities are explicit. Physical measures such as blocking an unused port can reduce access, but a removable plug, glued connector, or potting compound does not make a bypass impossible. Do not treat a tamperable barrier as the only protection for a safety function.
- Walk the delivered machine boundary against the asset and connection list; the expected reading is that every programmable asset and every route capable of reaching its programming interface has an identified owner and control.
Risk targets for safety and cybersecurity controls
Use the machine risk assessment to decide which safety performance the machine requires, then select controls that achieve that target. A Performance Level (PL) describes safety-related performance; a Security Level (SL) is a separate security concept. Do not treat one as a substitute for the other. The security assessment should identify what unauthorized access or program alteration could do to the machine, how likely access paths are to be used, and what preventive and detective measures are needed.
Turn the assessment into requirements that can be tested: who may access programming functions, how changes are authorized, what unauthorized attempts the system must detect, where those events are recorded, and who must respond. A measure that is easy to bypass does not become effective merely because it appears in a checklist. Add layered controls where the risk assessment calls for them—for example, access restrictions, physical controls, monitored routes, and a change approval process—then evaluate the achieved result against the target. The objective is risk reduction with evidence, not a paper trail detached from machine behavior.
- Compare the selected controls with the risk-assessment targets; the expected reading is a documented link from each significant risk to a preventive or detective measure and a verification method.
Event definition for illegitimate safety-program changes
Write an event policy before configuring message collection. Define what counts as illegitimate for the machine: an access attempt by an unapproved identity, an attempt outside the authorized maintenance process, or a programming action that lacks the required approval. Identify which event classes the controller or supporting system can actually report. Candidate classes include rejected access, programming-session activity, attempted program transfer, and changes to access protection; confirm the available events in the controller’s diagnostics and product documentation rather than assuming every device reports the same detail.
Keep attempted access distinct from a completed change. A rejected attempt should not be represented as a program modification, and an approved maintenance download should not be mislabeled as an attack. Record enough context to investigate: originating device or account when available, affected controller, event type, time, result, and the machine configuration involved. If a controller reports only some of these fields, capture the gap and decide whether a gateway or engineering system must supply the missing context.
- Exercise each defined event class in a controlled test; the expected reading is a distinct event for rejected unauthorized activity and a separate, correctly classified record for an approved change.
Event sources and controller-specific SYSLOG support
Choose event sources based on what they can detect, not on a vendor label. A controller can report a security event only if its hardware, firmware, configuration, and application support that event. Verify the controller documentation and diagnostic buffer for available security messages, and test the configured output. The fact that a machine contains a safety PLC does not by itself prove that failed or unauthorized programming attempts are being captured.
SYSLOG is an open standard for sending log messages; it is not limited to one manufacturer’s server. One cited implementation path uses security messages from S7-1200 or S7-1500 CPUs sent to a server, with library blocks as part of the PLC-side arrangement. Treat this as an implementation example, not a guarantee that every CPU or configuration emits every required event. For any PLC family, confirm the actual message source, event coverage, and server compatibility in that product’s documentation. Do not place sole reliance on volatile PLC memory: local storage can be limited, overwritten, or unavailable when the controller is damaged or replaced.
- Inspect the event-source configuration and controller diagnostics; the expected reading is that the tested unauthorized-access event appears with the correct controller identity and event result at the configured output.
Central log path, retention, and operator alerting
Route events to a controlled central store when the installation has a network path and an agreed server owner. Central collection makes it possible to correlate activity across PLCs, PCs, HMIs, SCADA systems, and routers rather than reviewing one controller at a time. It also separates event retention from the PLC’s limited local memory. The path is: event source, transport, receiving service, protected storage, and an assigned person or service that reviews alerts.
Define retention and access rules from the application’s legal, contractual, and operational needs; do not invent a universal retention period. Protect stored records from routine editing or deletion, restrict administrative access, and document how an investigator retrieves and exports records. Establish how event timestamps are set and interpreted across devices, especially if more than one controller contributes to the same incident. Configure an alert destination and response owner; a log that nobody receives or reviews has little operational value.
Test the behavior when the server or network path is unavailable. Do not assume messages are buffered or retransmitted unless the configured products document and demonstrate that behavior. If buffering is supported, determine its capacity and what happens when it fills. If it is not supported, define the fallback, such as local event capture and controlled retrieval, and decide whether the resulting detection delay is acceptable for the assessed risk.
| Architecture | Use | Verification point |
|---|---|---|
Central SYSLOG collection |
Correlate events across assets and support assigned monitoring. | Confirm receipt, timestamp, storage, alert routing, and loss-of-path behavior. |
| Local or isolated collection | Support machines without a routable path to the plant’s central server. | Confirm where records persist, who retrieves them, and how review is triggered. |
- Send a test event through the complete path; the expected reading is a searchable server record with a usable timestamp and a notification delivered to the named response owner.
Air-gapped machine logging and handoff to the plant
An air-gapped machine has no live route to a plant server, so a central network collector cannot provide immediate monitoring unless the architecture changes. Isolation does not remove the need to decide how events will be retained and reviewed. Select an approach that matches the assessed threat and delivery boundary: a logging service inside the machine boundary, a customer-provided isolated collector, or a controlled export process. Each has different response timing and ownership; document the selected approach rather than describing a disconnected machine as centrally monitored.
For an offline arrangement, define how records leave the machine, who performs the transfer, what authorization applies, and how the receiving party confirms completeness. If periodic retrieval is the chosen approach, state the review interval in the operating procedure based on the risk and operating context, rather than presenting it as a universal legal value. Account for the possibility that the machine may not be visited promptly. If that delay is incompatible with the response objective, the architecture needs an alert path or a different collector arrangement.
- Disconnect the central path during a controlled test and generate a test event; the expected reading is the documented offline behavior—retained local record, explicit transfer requirement, or a visible communication fault—not silent loss presented as successful monitoring.
OEM and end-user logging responsibility matrix
Assign an owner to every step from event generation through response. The machine builder should document what the delivered controller can emit, how it is configured, which assets and access routes fall within the machine boundary, and any limitations that affect monitoring. The plant owner or appointed third party can provide central storage and response, but only if the machine builder supplies the integration details and the receiving party accepts those responsibilities.
Use a handoff matrix to prevent assumptions at the boundary. Name the owner of the event source, network connection, server, retention policy, alert queue, maintenance account approval, and incident investigation. Include commissioning evidence and operational instructions with the machine documentation. If a third party is expected to implement storage, provide message-format and routing details available from the selected products, plus the expected test result. Do not promise that an OEM log is centrally retained when the customer has not provided a collector.
| Function | Owner to name | Handoff evidence |
|---|---|---|
| Generate and identify controller events | Machine builder or controller integrator | Configured event list and tested sample messages. |
| Receive and retain events | Plant owner or appointed service provider | Server endpoint, access rules, and retention procedure. |
| Review and respond to alerts | Named plant operations or security role | Alert routing and response instructions. |
- Review the signed commissioning handoff; the expected reading is a named owner for each row, a working endpoint where central collection is used, and no unresolved responsibility for event review.
End-to-end commissioning test for safety-program logging
Test the complete control chain without creating a hazardous machine state. Use a controlled machine state, an approved test account or test environment, and a procedure that prevents an unauthorized program change from being applied to production logic. Verify both security behavior and safe machine behavior: rejected access must remain rejected, and an approved maintenance action must follow the defined authorization path.
- Generate a controlled unauthorized access or programming attempt using the event class defined in the policy. Expected reading: the controller or designated event source reports a rejected attempt, and no program change takes effect.
- Follow the complete log route. Expected reading: the receiving store contains the correct asset, event class, result, and timestamp; the record is searchable and cannot be altered by ordinary machine operation.
- Confirm response ownership. Expected reading: the alert reaches the named operator or monitoring role, and the procedure identifies the action that role takes.
- Perform an approved maintenance change under the authorized process. Expected reading: the event is classified as authorized maintenance and can be distinguished from the rejected attempt.
- Interrupt the collector path under controlled conditions, generate a test event, then restore the path. Expected reading: the observed buffer, fault, or retrieval behavior matches the documented design; no unverified assumption of automatic delivery remains.
- Close the test by comparing the log with controller diagnostics and the machine change record. Expected reading: event counts and outcomes reconcile, any gaps have an assigned corrective action, and the machine is left in its approved configuration.
Questions about safety-program change logging
Why does a safety PLC need a separate logging path?
Controller memory may be limited or overwritten, and it does not automatically provide centralized review. A tested SYSLOG path or another documented collector can retain and correlate events outside the PLC.
Why does a machine without a safety PLC still need a scope review?
The absence of a safety PLC does not identify every programmable safety function, access path, or connected asset. Review the actual control architecture and risk assessment for each machine configuration.
Why is potting an unused RJ45 port not enough?
A physical obstruction can be removed or bypassed, so it cannot serve as the sole control for a safety-related programming path. Pair physical measures with access restrictions, monitored events, and verification appropriate to the assessed risk.
Why does an air-gapped machine still need an event-handling plan?
Air-gapping removes a live route to a plant server; it does not retain, review, or alert on events by itself. Specify local persistence or controlled retrieval, the responsible owner, and the response delay the risk assessment accepts.
How do I verify SYSLOG captures an unauthorized programming attempt?
In a controlled test, generate a defined rejected attempt and confirm that the central or local store shows the correct asset, event result, and timestamp, while the program remains unchanged. Then confirm that the assigned responder receives the alert.