When cybersecurity is added to an FA system integrator procurement, asking “Do you comply with IEC 62443?” or “Is remote maintenance secure?” is not enough. Factory owners, production engineering, procurement and OT security teams need to buy a service that defines who does what, when it is done, what evidence is delivered, and how a failure is corrected. This guide turns cybersecurity into requirements for the RFP, contract, FAT, SAT, maintenance acceptance and exit package of an automation project in Thailand.
It applies to new equipment and brownfield modifications involving PLCs, HMIs, robot cells, machine vision, SCADA, equipment-data collection and overseas remote support. The clauses below are not legal advice or a universal template. Calibrate them to safety impact, allowable downtime, interfaces, destination markets and the legal roles of the parties.
Executive conclusion: procure reproducible evidence, not a statement of intent
A useful RFP does not simply ask the integrator to “observe good security.” It names the asset inventory, configuration baseline, controlled remote access, individual accounts, patch decisions, restore tests, incident escalation, change log, subcontractor controls and exit package as deliverables. It then requires demonstrations at FAT/SAT and links them to acceptance and payment.
Three principles govern the design:
- Name the processes and justified exclusions that apply to the project, not only a standard.
- Verify implementation through configurations, logs and test records, not self-declaration.
- Continue responsibility through operations and contract exit, including emergency notification and access shutdown.
This guide complements our selection guide for Japanese FA system integrators in Thailand and the broader FA system integration responsibility guide. Its narrower purpose is to convert those responsibility boundaries into deliverable evidence and acceptance tests.
1. Why revise procurement requirements in 2026
Thailand’s TIS 62443 Part 2(4)-2568 is in effect
The Thai Industrial Standards Institute lists TIS 62443 Part 2(4)-2568, Security for industrial automation and control systems—Part 2-4: Security program requirements for IACS service providers. It took effect on 9 May 2026 and replaced TIS 62443 Part 2(4)-2561. TISI information states that the older Thai edition was identical to IEC 62443-2-4:2015. Do not state that the 2568 edition is identical to IEC 62443-2-4:2023 unless an authoritative source explicitly proves it.
The practical procurement response is not a one-line “TIS compliance” requirement. Ask bidders to identify the edition, scope, processes delivered, evidence, and exceptions. A certificate alone does not automatically prove that the configuration or operating process for this project is secure.
IEC 62443-2-4:2023 examines service-provider processes
IEC 62443-2-4:2023 Edition 2.0 was published on 15 December 2023. It defines security-related processes that an IACS service provider can offer during integration and maintenance of an Automation Solution. Because it permits profiles or subsets for different environments, it should not be read as requiring every clause at identical strength in every project.
Instead of a yes/no question, require a response table with the process offered, requirements not applied, compensating controls, evidence name and delivery date. That makes competing proposals comparable.
EU-market products need supplier evidence that supports CRA reporting
Cyber Resilience Act Article 14 reporting obligations began on 11 September 2026. Manufacturers of products with digital elements report actively exploited vulnerabilities and severe incidents through ENISA’s Single Reporting Platform. The early warning is due within 24 hours of awareness and a fuller notification within 72 hours. For an actively exploited vulnerability, a final report is due within 14 days after a corrective or mitigating measure becomes available; for a severe incident, the final report is due within one month of the 72-hour notification.
This does not mean that every Thai FA integrator is automatically the CRA “manufacturer.” Legal counsel must determine the role based on the contract, product and EU-market activity. The operational question is whether an EU-market machine or equipment manufacturer can quickly obtain detection time, affected assets, versions, mitigation and accountable contacts from the integrator and suppliers. ENISA’s platform is a reporting channel, not a certification portal.
A VPN alone does not complete remote-maintenance security
CISA remote-access guidance warns that the historical trust relationship between a vendor and operator cannot be assumed safe. A compromise at the vendor may piggyback on a trusted connection. A VPN can protect a transport path, but on its own it does not prove who approved the session, which endpoint was used, how long access remained active, which asset was reached or what changed.
According to project risk, combine named approval, MFA, a jump host, time-bounded enablement, least privilege, session logging and emergency disablement, and demonstrate them at SAT. CISA procurement language is a useful informative toolkit—not a standard or mandatory policy—and should be adapted rather than copied as a one-size-fits-all clause.

2. Decisions the owner must make before issuing the RFP
An integrator’s answer cannot be more precise than the owner’s boundary. Before tender, put the following on one project sheet:
- In-scope equipment: PLC, HMI, industrial PC, robot, vision, SCADA, server, switch and gateway
- Process and consequence: effects of downtime on safety, quality and delivery
- Interfaces: factory OT, enterprise IT, cloud, OEM and overseas sites
- Data: recipes, programs, quality images, personal data, credentials and logs
- Lifecycle: design, build, installation, warranty, maintenance, modification and exit
- Decision owners: equipment owner, production engineering, IT/OT, safety, quality, procurement and legal
- Recovery objective: what must be restored, in what order and to which approved point
- Market context: Thailand-only use or relation to products/machinery placed on the EU market
Draw the Automation Solution boundary, not only an asset list
A scope limited to the PLC and VPN appliance can omit the engineering laptop, backup medium, licence server and OEM relay machine. In addition to the network diagram, map where programs are created, who approves them, how they are transported, where they are stored and who restores them.
Review safety and security changes together
Security hardening may delay maintenance, a patch may alter PLC communication, or extra logging may load an industrial PC. Put security impact, safety impact, production impact and rollback criteria on the same change record. Separate email approvals for safety and cybersecurity create a final configuration that nobody fully owns.
3. RFP evidence matrix for FA system integrator cybersecurity
The following is a practical minimum. Add or remove items based on criticality and architecture, but assign an evidence format and due date to every adopted requirement.
| Control topic | Requirement in RFP | Contract deliverable | Evidence at FAT/SAT | Evidence during maintenance |
|---|---|---|---|---|
| Roles and contacts | Responsibilities and deputies for owner, integrator, OEM and subcontractor | RACI, contact tree, escalation table | Communication exercise record | Contact-change history |
| Asset inventory | Model, serial, firmware/software, IP, role and support end date | Machine-readable inventory and architecture | Sample match against physical assets | Add/remove delta |
| Configuration baseline | Secure settings, prohibited services, exceptions and approver | Approved configuration sheet and exports | Difference from device settings | Periodic difference record |
| Accounts | Individual IDs, privilege, service IDs, expiry, leaver/mover process | Account register and lifecycle procedure | No shared ID, or approved exception | Create/change/disable logs |
| Remote maintenance | Approval, MFA, path, targets, time limit, recording and kill switch | Connection design, SOP and emergency-disable procedure | Allow, deny, expiry and log demonstration | Session record and approval ticket |
| Vulnerability and patch | Sources, assessment time, test, deployment and compensating control | Workflow, compatibility responsibility and notification SLA | Sample vulnerability decision | Open register and exception expiry |
| Backup and restore | Scope, frequency, encryption, storage and restore order | Backup design and golden copy | Restore into a clean environment | Restore-test record |
| Logs and time | Events, destination, time sync and viewing rights | Log catalogue, retention and export procedure | Connection/change/failure logs | Gap and review record |
| Incident handling | Detection, initial notice, evidence preservation and containment support | Response/notification procedure and time commitments | Tabletop or technical exercise | Case ticket and corrective action |
| Change control | Request, impact, approval, test and rollback | Change template and baseline | Detect an unapproved change | Change log and current version |
| Subcontractors | Company, person, access, data and equivalent duties | Subcontractor register and flow-down clause | Sample evidence | Approval for additions |
| Handover and exit | Design, source, keys, backup and account disablement | Exit-package list | Handover rehearsal | Receipt, revocation log and deletion evidence |
Weight project-specific evidence more than generic policy
An integrator may have a polished corporate policy that never reaches the project PLC or OEM account. Score process description, project-specific examples, demonstrability, transparent exceptions and maintenance continuity separately. Define minimum pass conditions before combining security and price scores.
Five fields for every standards-conformance answer
- Standard, edition and profile
- Services in scope and out of scope
- Internal process that fulfils the requirement
- Evidence delivered for this project
- Deviation, compensating control and approver
Answers such as “planned compliance” or “we follow best practice” are not yet contractable commitments.
4. Remove ambiguity from contract clauses
Tie security deliverables to milestones and payment
If an operational machine is the only acceptance criterion, inventories, backups, logs and account clean-up will be deferred. Allocate mandatory deliverables to design approval, FAT, SAT and final handover. Define conditional acceptance, correction periods and responsibility for retest cost.
A notification SLA needs a starting point, route and minimum content
“Notify promptly” cannot be compared or tested. Define whether time starts when the integrator observes an event or reaches a stated confidence level, and separate routine and emergency channels. The initial notice should include at least discovery time, potentially affected scope, versions, current containment and the next update time. Where the contract supports a CRA-regulated manufacturer, design supplier notification so the manufacturer can assess its 24-hour and 72-hour obligations. Avoid wording that mistakenly assumes the integrator automatically inherits the manufacturer’s legal role.
Separate the right to know from the right to change
Receiving vulnerability notices, viewing component information, reading logs and approving device changes are distinct rights. A contract that permits unapproved emergency patching is risky, but so is one in which the integrator can do nothing without an unreachable owner. Define separate paths for urgent containment, permanent remediation and normal change.
Make subcontractor and OEM access visible
The bidder’s engineers may not be the only people who connect. An overseas OEM, panel builder or software company may do the work. Register the organisation, country, connection method, data, privilege and contract expiry. Require prior approval for additions, flow equivalent duties into subcontracts, and make the prime integrator responsible for producing evidence.
5. Acceptance design for secure OT remote maintenance

Treat remote maintenance as an approved work session, not merely as a convenient network connection.
Before the session
- Use a named individual identity; prohibit shared IDs by default.
- Record work order, target assets, purpose, planned start/end and approver.
- Require MFA and a managed endpoint according to risk.
- Restrict the destination to required assets and prevent lateral movement.
- Enable access only for the approved period, not permanently.
- Define minimum controls for the vendor endpoint and notice after vendor compromise.
During the session
- Consolidate the path through a jump host where appropriate.
- Retain login, target, start/end and command or session records.
- Control file transfer, clipboard and removable media.
- Require separate approval for privilege elevation.
- Let the factory see an active session and terminate it immediately.
After the session
- Return work performed, changed files, configuration differences, restarts and test results to the work order.
- Expire temporary IDs, rules and files.
- Update the baseline, inventory and backup.
- Review failed actions and anomalous traffic.
- Confirm that the next session is not automatically permitted.
Demonstrate negative tests at SAT
A successful connection is only half the test. Verify that an unapproved ID, expired approval, wrong destination and MFA failure are denied; that emergency shutdown prevents reconnection; and that the owner can export the access record. If video recording is prohibited, agree alternative evidence such as command audit, redacted screenshots and witnessed execution.
6. Accept decision quality, not a patch-rate number
Immediate patching may be impossible in OT because of compatibility, outage windows, safety approval or vendor support. Yet “we do not patch production equipment” is not management.
Require the following record:
- Products and components monitored
- Advisory sources and review frequency
- Impact analysis: product, version, exposure, exploitation and process impact
- Decision: deploy, defer, not applicable or compensating control
- Compatibility test and rollback procedure
- Deferral expiry, reassessment date and approver
- Owner notification time and content
At FAT, route a fictional vulnerability ticket through the process and observe who matches it to the inventory, decides and retains evidence. At SAT, confirm compensating controls and expiry dates in the real environment.
7. Measure backup by restoration capability, not file delivery
A PLC project folder is not recoverable if the correct engineering software, licence, libraries, firmware, communications and recipes are missing. A golden copy should include:
- PLC/HMI/robot/vision/SCADA projects and deployed versions
- Engineering software and versions, plus licence-recovery method
- Network, user, time-sync and certificate settings
- Recipes, calibration and safety-relevant parameters
- Configuration hash, approval date, approver and change number
- Restore sequence, dependencies and functional verification
Restore from an empty state in an isolated environment, spare device or virtual environment without risking production. Verify startup, communication, I/O or simulation, recipe consistency and login. A “backup job succeeded” screen is not equivalent to recovery. Recovery time is a project agreement based on process and safety, not a universal statutory value.
8. Cybersecurity acceptance checklist for FAT and SAT

FAT verifies design and function in the integrator/OEM environment. SAT repeats environment-dependent tests on the factory network and under factory operating procedures.
| Acceptance item | FAT | SAT | Passing evidence |
|---|---|---|---|
| Asset inventory | Match design BOM to build | Sample physical items, IPs and links | Signed register; no delta or approved exception |
| Baseline | Export configuration | Re-acquire and compare live settings | Comparison and exception ID |
| Accounts | Review roles, privilege and defaults | Test named, expired and emergency IDs | Register and test logs |
| Remote access | Demonstrate allow, deny and expiry | Demonstrate approval, shutdown and logging on factory path | Approval ticket, log, shutdown record |
| Logs and time | Generate required events | Search and export at collection point | Event timestamps and exported file |
| Change control | Request and roll back a sample | Execute a real change through approval | Ticket, difference and rollback result |
| Vulnerability | Decide a sample case | Review live register and mitigations | Assessment, expiry and approval |
| Backup | Produce golden copy | Confirm factory location and access | Hash and custody record |
| Restore | Restore in isolation | Partial restore or exercise within safe limit | Duration, function result and issues |
| Incident notification | Tabletop test | Check contact route and initial data | Timeline and receipt confirmation |
| Subcontractor | Match identities and rights | Match actual connecting party | Register, approval and contract evidence |
| Exit | Review draft package | Deliver final, disable IDs and return keys | Receipt, revocation and deletion evidence |
Define pass, conditional pass and fail
A checkbox is not a decision rule. Defects affecting safe shutdown, an unauthorised external connection, unmanaged administrator sharing or inability to restore may be major nonconformities and shipment/startup gates. A minor document error may be conditionally accepted with a deadline. Define classification, correction time, retest scope and approval authority before award.
Do not overexpose secrets in evidence
Define redaction so screenshots do not disclose passwords, private keys or personal data. Store configuration securely and reference it from the acceptance record. Hashes and version numbers help confirm integrity, but a matching hash alone does not prove the configuration is appropriate.
9. Example 90-day post-startup plan
This is an implementation example, not a statutory deadline or universal SLA. For a 1 October 2026 startup:
| Period | Objective | Main activities | Exit evidence |
|---|---|---|---|
| Day 1–14 (1–14 Oct) | Stabilise baseline | Final inventory, configuration, identity and connection check | Baseline v1 and open-item register |
| Day 15–31 (15–31 Oct) | Embed operations | Review real sessions and audit changes | Log review and corrective tickets |
| Day 32–61 (1–30 Nov) | Prove recovery | Verify backup and exercise restore | Restore record and updated procedure |
| Day 62–90 (1–29 Dec) | Accept maintenance | Vulnerability ticket, contact exercise and exit-package update | 90-day review and issue owners |
This example uses 1 October 2026 as Day 1, so Day 90 is 29 December. Do not casually translate it into “three months”; state in the contract that the schedule uses a Day 1 baseline and calendar days.
10. Red flags in integrator proposals
- “Full IEC 62443 compliance” with no edition, scope, evidence or exclusion
- A claim that the VPN alone makes access secure
- An OEM shared account with no justified exception
- An inventory containing model and quantity but no version, IP or support date
- Backup delivery without a restore test
- Vulnerability notice with no clock start or named route
- Undisclosed subcontractors or overseas support locations
- Logs visible only to the integrator and not exportable to the owner
- A demonstration at FAT but an exclusion from SAT
- No exit requirement for IDs, keys, source and configurations
A single red flag need not automatically disqualify a bidder. Where a technical constraint exists, require a documented risk, time limit, compensating control and approver.
11. Operating governance: what to review monthly
Raw counts can reward the wrong behaviour. Review expired accounts, unapproved sessions, baseline deviations, overdue vulnerability decisions, failed restore tests, unreachable contacts and subcontractor changes. Give every metric a denominator, scope and exception rule.
To avoid framing availability and security as opposites, track decision quality: compensating controls completed on time, changes with prepared rollback, and time to reconcile physical assets with the register. For response and recovery exercises, combine this contract-evidence approach with our Thailand OT cyber incident-response drill guide.
Conclusion: build one evidence chain from RFP to exit
The most important result of FA system integrator cybersecurity is a traceable chain from requirement, design and configuration to test, operation, change and exit. TIS 62443 Part 2(4)-2568 and IEC 62443-2-4:2023 provide a useful process structure, but procurement needs a project-specific profile, scope, exceptions and acceptance evidence. Do not stop remote-access design at a VPN: test approval, identity, time, target, recording and emergency termination. For EU-market products, determine the CRA legal role separately while contracting for supplier information that enables timely manufacturer assessment.
If you are preparing an automation RFP, renewing an integrator contract or defining FAT/SAT evidence for a Thai factory, you can contact TOMAS TECH while the project is still at the concept stage. We can help structure deliverables, responsibility boundaries and acceptance tests around your installed base and downtime constraints.
FAQ
Is an IEC 62443 certificate sufficient for FA system integrator cybersecurity?
Not necessarily. Confirm the certified organisation, edition and scope, then contract the processes, project evidence, exclusions and compensating controls. An integrator without a certificate should not be rejected automatically; its equivalent processes and evidence can be assessed explicitly.
Should the RFP cite IEC 62443-2-4 or TIS 62443-2-4?
Choose according to the Thai contract, customer requirements and destination market. Always identify the edition and request a mapping table. Do not assert equivalence between the TIS 2568 and IEC 2023 editions without official evidence.
Are VPN and MFA enough for OT remote maintenance?
No. Include named approval, time-bounded access, destination restriction, a controlled jump path, least privilege, session records, emergency disablement and post-work expiry. Test denial cases at SAT.
Must FAT and SAT repeat the same tests?
They serve different purposes. FAT checks design and function in the supplier environment; SAT verifies operation with the factory network, identities, time source, people and kill switch. Reuse evidence for low-risk static items, but repeat environment-dependent tests.
Should CRA deadlines be copied directly into an integrator contract?
Not automatically. First determine the manufacturer and other legal roles. Then work backward from the manufacturer’s 24-hour and 72-hour assessment needs to define supplier notice content and timing.
What is the minimum backup acceptance test?
Restore in isolation and verify required software, licences, communication, I/O or simulation, recipes and accounts—not merely file presence. Record duration and unresolved dependencies.
What if a legacy asset cannot support named accounts or logging?
Register the asset, reason, risk, expiry, compensating controls and approver. A jump host that identifies the user, controlled physical keys, witnessed work and signed work orders can be layered, depending on risk.
How should price and security be combined in RFP scoring?
Set minimum pass criteria for major security items first, then apply a total-cost evaluation. A low bid that leaves uncontrolled external access or an untestable restore may create much higher lifecycle cost.
References
- TISI: TIS 62443 Part 2(4)-2568
- TISI: TIS 62443 Part 2(4)-2561
- IEC 62443-2-4:2023
- European Commission: CRA reporting
- ENISA: Single Reporting Platform
- EU Regulation 2024/2847
- CISA: ICS Recommended Practices
- CISA: Cybersecurity Procurement Language
- CISA: Managing Remote Access
- NIST SP 1800-10
- Siemens at AMB Stuttgart 2026