Safe Remote Access for Your Machine Vendor

When a new machine is installed, the builder almost always asks for the same thing: the ability to connect remotely when something breaks. The request is reasonable — half an hour of remote diagnosis beats three days waiting for a flight.

The problem is not the request but the implementation. In most plants it ends up like this: the builder brings a box, plugs it in beside the machine, gives it its own internet connection, and everyone forgets about it for years. Nobody knows who connected, when, or to what. If that box also touches the office network, the plant now has a second door to the outside — and you do not hold the key.

Why the usual shortcuts fail

• A remote desktop tool left running. Installed on the operator PC with a shared password, it becomes a door anyone can walk through.
• The vendor's own box with its own internet line. It never passes your firewall, keeps no logs, and on the day you want it switched off, nobody is sure how.
• A shared account. When five engineers use one login called "service", no one can say afterwards who connected.
• A path into the office network. The builder needs one machine. There is no reason for that session to see the accounting server.

The arrangement that works: open the door on request

The goal is not to block access but to control it. What holds up in practice:

• Access is granted on request. The builder reports a fault, the connection is opened, and it is closed when the work ends. No permanent path exists.
• Named account with a second factor. You know who connected, and a password alone is not enough to get in.
• Reach limited to that machine. The session sees the machine's network segment and nothing else.
• Time limit. Access is granted for a window of a few hours and expires on its own.
• Logging. Who connected, when, for how long, and where possible a session recording. The record protects both sides.
• Someone on the floor. A person stays at the machine during the session; a remote change can move equipment.

If the vendor insists on their own hardware

Some builders require their own remote access device. In that case, negotiate these points: the box connects to the machine network only, not the office network; it reaches the internet through your firewall; the connection is enabled only when needed; and you hold the device's management password too. If none of that is accepted, the last resort is giving the box a separate line and isolating it from the machine network as well.

Three clauses for the contract

• Remote access is opened on request and with the plant's approval.
• Connections use a named account; credentials are not shared.
• Changes are reported in writing, and an updated source project is handed over after any program change.

That third clause also settles the "where is the program" problem before a controller ever fails.

How Yamanlar Bilişim helps

Our part is building that access path and tying it to a record: separating the machine network, granting limited access on request, issuing named accounts, keeping connection logs, and writing a short usage note to share with the builder. We do not touch the machine's program. Network design sits in our network infrastructure work, access and monitoring in enterprise cyber security, and production-specific work on the manufacturing and workshops page.

Frequently asked questions