Blog

2026.09.16

FA System Integrator Cybersecurity — Thailand RFP and Acceptance Evidence Guide 2026

FA System Integrator Cybersecurity — Thailand RFP and Acceptance Evidence Guide 2026

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:

  1. Name the processes and justified exclusions that apply to the project, not only a standard.
  2. Verify implementation through configurations, logs and test records, not self-declaration.
  3. 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.

FA System Integrator Cybersecurity — Thailand RFP and Acceptance Evidence Guide 2026 - figure 1

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 topicRequirement in RFPContract deliverableEvidence at FAT/SATEvidence during maintenance
Roles and contactsResponsibilities and deputies for owner, integrator, OEM and subcontractorRACI, contact tree, escalation tableCommunication exercise recordContact-change history
Asset inventoryModel, serial, firmware/software, IP, role and support end dateMachine-readable inventory and architectureSample match against physical assetsAdd/remove delta
Configuration baselineSecure settings, prohibited services, exceptions and approverApproved configuration sheet and exportsDifference from device settingsPeriodic difference record
AccountsIndividual IDs, privilege, service IDs, expiry, leaver/mover processAccount register and lifecycle procedureNo shared ID, or approved exceptionCreate/change/disable logs
Remote maintenanceApproval, MFA, path, targets, time limit, recording and kill switchConnection design, SOP and emergency-disable procedureAllow, deny, expiry and log demonstrationSession record and approval ticket
Vulnerability and patchSources, assessment time, test, deployment and compensating controlWorkflow, compatibility responsibility and notification SLASample vulnerability decisionOpen register and exception expiry
Backup and restoreScope, frequency, encryption, storage and restore orderBackup design and golden copyRestore into a clean environmentRestore-test record
Logs and timeEvents, destination, time sync and viewing rightsLog catalogue, retention and export procedureConnection/change/failure logsGap and review record
Incident handlingDetection, initial notice, evidence preservation and containment supportResponse/notification procedure and time commitmentsTabletop or technical exerciseCase ticket and corrective action
Change controlRequest, impact, approval, test and rollbackChange template and baselineDetect an unapproved changeChange log and current version
SubcontractorsCompany, person, access, data and equivalent dutiesSubcontractor register and flow-down clauseSample evidenceApproval for additions
Handover and exitDesign, source, keys, backup and account disablementExit-package listHandover rehearsalReceipt, 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

  1. Standard, edition and profile
  2. Services in scope and out of scope
  3. Internal process that fulfils the requirement
  4. Evidence delivered for this project
  5. 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

FA System Integrator Cybersecurity — Thailand RFP and Acceptance Evidence Guide 2026 - figure 2

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

FA System Integrator Cybersecurity — Thailand RFP and Acceptance Evidence Guide 2026 - figure 3

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 itemFATSATPassing evidence
Asset inventoryMatch design BOM to buildSample physical items, IPs and linksSigned register; no delta or approved exception
BaselineExport configurationRe-acquire and compare live settingsComparison and exception ID
AccountsReview roles, privilege and defaultsTest named, expired and emergency IDsRegister and test logs
Remote accessDemonstrate allow, deny and expiryDemonstrate approval, shutdown and logging on factory pathApproval ticket, log, shutdown record
Logs and timeGenerate required eventsSearch and export at collection pointEvent timestamps and exported file
Change controlRequest and roll back a sampleExecute a real change through approvalTicket, difference and rollback result
VulnerabilityDecide a sample caseReview live register and mitigationsAssessment, expiry and approval
BackupProduce golden copyConfirm factory location and accessHash and custody record
RestoreRestore in isolationPartial restore or exercise within safe limitDuration, function result and issues
Incident notificationTabletop testCheck contact route and initial dataTimeline and receipt confirmation
SubcontractorMatch identities and rightsMatch actual connecting partyRegister, approval and contract evidence
ExitReview draft packageDeliver final, disable IDs and return keysReceipt, 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:

PeriodObjectiveMain activitiesExit evidence
Day 1–14 (1–14 Oct)Stabilise baselineFinal inventory, configuration, identity and connection checkBaseline v1 and open-item register
Day 15–31 (15–31 Oct)Embed operationsReview real sessions and audit changesLog review and corrective tickets
Day 32–61 (1–30 Nov)Prove recoveryVerify backup and exercise restoreRestore record and updated procedure
Day 62–90 (1–29 Dec)Accept maintenanceVulnerability ticket, contact exercise and exit-package update90-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