Your organisation has demonstrable control of critical OT data only when every relevant copy, transfer and recipient is governed. Access to a PLC, SCADA environment or historian may be technically restricted, while configuration files, network diagrams, maintenance reports and exports still circulate more widely through email, cloud links or supplier portals. Effective OT data governance therefore combines classification, least privilege, strong verification, limited validity, revocable access and logging. Secure file transfer can control external file exchange, but it does not secure the OT network itself or replace segmentation, asset management, endpoint protection or controlled remote access.
What counts as critical OT data?
Operational technology covers systems and devices that monitor or control physical processes. The UK National Cyber Security Centre includes ICS, SCADA and distributed control systems in its definition of OT. The associated data is broader than live process values on an operator screen. Information required to understand, maintain, recover or change the environment may also be critical.
Examples include configuration and backup files, firmware packages, asset inventories, IP addresses, network and architecture diagrams, PLC or HMI project files, alarm and event logs, historian exports, vulnerability reports, maintenance instructions, engineering drawings, change records and forensic evidence. Not every file requires identical protection. Its potential effect on safety, availability, quality, intellectual property and recovery should determine the level of control.
Data that leaves the OT environment
OT data is frequently processed outside the immediate production environment. An engineer exports logs for analysis, an original equipment manufacturer receives a configuration for support, an integrator supplies updated software or an auditor requests evidence. At that point the security problem changes. Network segmentation protects the OT boundary, but it does not automatically govern what happens to an exported copy afterwards.
Why copies matter as much as source systems
A locally downloaded configuration can expose the same sensitive detail as the file held inside the OT system. An obsolete drawing can also create operational risk if it is reused later. Inventory the most important information flows and formal handover points as well as the systems themselves. Define who owns the source, who may create an export and when copies must expire or be deleted.
Who can access OT data in practice?
The formal authorisation list rarely provides the complete answer. Access is created through accounts, but also through shared mailboxes, project folders, exports, ticketing systems, backups and downloads. Distinguish direct system access from access to a copy of OT data. Both can create exposure, but they require different controls.
Employees, engineers and administrators
Operators, maintenance engineers, process engineers, IT administrators, security teams and managers have different information needs. A job title should not confer access to every category of OT data. Assign permissions by task, site, project and duration. Avoid shared accounts where individual accountability is necessary, and align access with joiner, mover and leaver processes.
Suppliers, integrators and maintenance partners
External specialists are often essential for maintenance, fault analysis and change work. Their assignment is normally temporary and specific, yet accounts, shared folders or downloaded files can survive long after completion. Record the data each party needs, its purpose, the permitted period and the internal approver. Include subcontractors in the assessment: the contracting company is not always the person who ultimately receives the file.
Applications, integrations and service accounts
Systems also have access. Monitoring platforms, data lakes, backup software, maintenance portals, SIEM integrations and export scripts may all process OT information. Service accounts commonly receive broad, long-lived permissions. Include these identities in the inventory, restrict their scope, manage secrets centrally and verify that each connection still has a documented business purpose.
Why access becomes broader than intended
Excess access usually results from accumulated practical exceptions rather than one dramatic mistake. A supplier urgently needs a log, a project folder is reused, a link is created without an expiry date or an engineer turns to personal storage because the approved channel rejects a large file. Each decision may be understandable in isolation; together they create an information chain that nobody can fully explain.
- project and supplier permissions remain active after the work ends;
- shared accounts prevent attribution to an individual;
- download links can be forwarded or remain active unnecessarily;
- the same export exists in mailboxes, local folders and supplier portals;
- classification and sharing rules differ between sites or departments;
- logs are fragmented and cannot produce a coherent timeline;
- the approved route is harder to use than a generic transfer service.
The starting point is therefore a clear process, not simply more access technology. Which OT data may cross the boundary? Who decides? Which channel is approved for each risk level? Which events must be evidenced? Technical controls can then be configured against explicit decisions.
What good access control for OT data looks like
The NIST Guide to Operational Technology Security treats OT security in the context of its distinctive performance, reliability and safety requirements. Core access principles remain familiar, but they must operate across the entire transfer lifecycle: selection, approval, sharing, receipt, download, retention and deletion.
Least privilege and separation of duties
Give a recipient access only to the approved package needed for the assignment. Access to a maintenance report should not imply access to the entire project workspace or OT environment. For high-impact configurations, separate preparation, approval and distribution where appropriate. This prevents one individual from preparing and disseminating a critical change without independent oversight.
Strong identity and recipient verification
An email address or possession of a link is not always sufficient evidence of identity. Use named accounts, strong authentication and risk-based verification for external recipients. Central SSO and lifecycle management help govern employees; a second factor may be appropriate for sensitive transfers to third parties. See why 2FA is an important additional barrier for digital access. Balance assurance with usability so that staff continue to use the approved route.
Expiry, revocation and retention
Temporary collaboration calls for temporary access. Apply an appropriate expiry date, revoke access when the purpose ends and define retention for the file and its audit evidence. One limitation matters: revocation prevents future access to the transfer environment, but it cannot automatically erase a copy that has already been legitimately downloaded. Combine technology with classification, contractual obligations and a conscious decision about whether downloading is necessary.
Logging, review and evidence
A log adds value only when the organisation knows which question it must answer. Record relevant events, protect audit data against unauthorised change and assign responsibility for periodic review. Look beyond incidents to persistent exceptions, such as ownerless accounts, long-lived links, dormant supplier permissions and transfers outside the approved process.
OT file exchange is not the same as remote OT access
Remote access allows an external user to operate or administer systems. File exchange delivers or receives a defined information package. These activities have different risk profiles. International guidance on secure connectivity for operational technology emphasises limiting exposure, centralising connections, hardening the OT boundary and logging and monitoring connectivity. These objectives require measures such as segmentation, jump hosts, session controls and specialised privileged-access capabilities.
Secure file transfer does not replace those measures. It is appropriate when an approved file package can be exchanged without giving a third party broader access to the OT network, an engineering workstation or a collaboration environment. If a supplier needs both files and a remote session, authorise, protect and log the two paths separately.
How Msafe supports controlled exchange of OT-related files
Msafe Secure File Transfer is designed for controlled external file exchange between people and organisations. It can provide a transfer layer for log exports, engineering drawings, maintenance records, configuration backups and incident information after those files have been deliberately released from the OT environment. Feature availability depends on configuration and licence; implementation should always follow the organisation’s risk assessment and OT policy.
Controlled sharing beyond the OT boundary
The sender shares a selected file or record set with named recipients without automatically granting access to the source system. Encryption, recipient verification, permissions, expiry and revocation help constrain the transfer. Very sensitive material still needs content approval before release: a secure channel does not make unnecessary disclosure appropriate.
Integration without weakening policy
Single sign-on through Microsoft Entra ID, SCIM, roles, Outlook integration and APIs can connect the approved route to existing workflows. The objective is not to export every OT file automatically. Automate only an authorised process with a defined source, destination, classification, error path and owner. Retain human approval when the consequence of the wrong file or recipient is material.
Audit trails for investigation and assurance
Audit trails and reports provide factual information about transfers and the access conditions applied. This can support incident investigation, supplier reviews, internal control and audits. It is a practical application of compliance by design for secure file sharing: policy is translated into defaults, technical safeguards and evidence. An audit trail does not prove overall compliance or OT security by itself; it helps demonstrate how a particular transfer was performed.
What evidence should you be able to produce?
When a security officer, auditor, customer or incident team asks who had access, the answer should be based on evidence rather than assumption. For a high-risk OT file transfer, an organisation will commonly need to reconstruct:
- who selected, approved and sent the file;
- which recipient received access and how identity was verified;
- which file version, classification and access conditions applied;
- when the transfer was created, opened and downloaded;
- when permissions changed, expired or were revoked;
- which exception was approved, by whom and for what reason;
- how an anomaly or incident was investigated and closed.
Connect this evidence to the wider OT picture. Guidance on maintaining a definitive view of OT architecture highlights the need to identify assets, connectivity and third-party risk. File flows and recipients should form part of that working understanding. Collect evidence purposefully and protect the logs themselves; unlimited logging without ownership or retention rules is not a mature control. Read what NIS2 asks of organisations on our NIS2 page.
A practical roadmap for regaining control of OT data access
- Identify critical OT data. Find the files and exports needed to design, operate, change, recover or investigate OT. Classify their potential impact.
- Map the data flows. Record where data originates, who creates exports, which channels are used, where copies land and when they should be removed.
- Inventory people and systems. Include employees, suppliers, service accounts, integrations, shared mailboxes and external portals. Assign an owner and purpose to every access path.
- Define decision rules. Set mandatory approval, recipient verification, permissions, validity, download options, retention and logging for each classification.
- Separate transfer from remote access. Apply the right control to each purpose. Do not grant broad system access when a defined file package is sufficient.
- Test the approved route with real scenarios. Use representative files, temporary suppliers and incident exercises. Verify that revocation, expiry, logging and offboarding work in practice.
- Review and improve. Remove orphaned access, investigate shadow channels, refresh classification and adjust controls as OT, suppliers and regulation change.
The same principles apply to large CAD files, scans and engineering records. See the practical guidance on securely sharing large files in construction and industry. For an example of a high-tech manufacturer sharing technical data securely with suppliers, read the PAL-V customer case.
Frequently asked questions about access to OT data
What is OT data?
OT data includes process values and the information needed to understand, maintain, modify or recover an OT environment. Examples include configurations, firmware, asset inventories, network diagrams, logs, historian exports, maintenance records and engineering drawings. Sensitivity depends on the potential effect on safety, availability, quality, intellectual property and recovery.
Is IT security sufficient for OT data?
Not without adaptation to the OT context. Familiar principles such as least privilege, MFA, encryption and logging remain relevant, but implementation must account for safety, availability, long asset lifecycles, restricted maintenance windows and legacy systems. OT and IT owners should therefore make classification and access decisions together.
Does Msafe secure the OT network itself?
No. Msafe is not a platform for network segmentation, OT asset discovery, endpoint protection, PLC management or privileged remote access. Msafe Secure File Transfer supports controlled exchange of selected OT-related files beyond the OT boundary. It is one control within a layered OT security approach.
How should suppliers receive OT files?
Share only the approved package needed for a defined purpose. Use a named recipient, strong verification, restricted permissions and an expiry date. Record the transfer, revoke access when the assignment ends and address local copies, confidentiality, incidents and deletion in supplier agreements.
Why is an audit trail important?
An audit trail helps reconstruct who shared a file, which recipient obtained access, which conditions applied and when relevant events occurred. This supports incident investigation, control testing and supplier review. The organisation must still define which events matter, who reviews them and how long they are retained.
How does NIS2 relate to OT data?
NIS2 requires in-scope organisations to implement appropriate and proportionate cybersecurity risk-management measures, including aspects of supply-chain security and access control. Exact obligations depend on jurisdiction, sector, size, role and risk. Secure file transfer can support particular access and evidence controls, but it does not make an organisation compliant on its own.
From unknown access to demonstrable control
The decisive question is not whether the OT network appears isolated on paper, but whether the organisation can demonstrate who can access the data used to operate, maintain and recover it. That requires visibility of exports and copies, accountable owners, time-limited permissions, strong verification and useful evidence. A structured, continuously maintained understanding of the OT environment is essential. Msafe can make selected external file transfers controlled and usable without suggesting that one product solves OT security as a whole. Request a demo or Proof of Concept and test a real supplier transfer against your own access and audit requirements.
Please note: this article provides general information and is not legal advice or technical security advice for a specific OT environment. Validate the final design against your risk assessment, safety objectives, architecture, contracts and applicable regulation.
