Episode 02 / Factory reality · 8 minutes 6 seconds
OEM access without losing control
Set expectations for vendor access: approval, communication boundaries, session records and a clear way to revoke access.
Agree the purpose and scope.
Name the owner, target equipment, authorised activity and access window.
Keep reviewable session records.
Record who connected, which targets were used, the activity and the result.
Verify that access has ended.
Agree a safe way to close the session, revoke access and verify closure.
Read the full transcript
OEM access without losing control
My name is Sam Armstrong, a senior developer for OTCogniShield.
Vendor support can keep production moving. Access still needs clear boundaries.
We will follow one support request, from approval to verified closure.
Start with a real operational need.
Imagine a packaging machine with an intermittent fault and unfamiliar alarm.
The supplier offers remote support. First, establish what help is needed.
A support contract does not automatically authorise unrestricted factory access.
Write a short support brief.
Describe the fault, affected equipment and the expected outcome.
Ask which tools and connections the supplier needs, including file transfers.
Separate viewing diagnostics from changing software, settings or controller logic.
Name the person who can approve.
Name the site owner who approves access and assesses operational consequences.
The supplier requests access; the site authority approves the agreed scope.
Record approval before connection, with the support ticket and responsible contacts.
Agree what is allowed, and when.
Specify targets, services, permitted actions and the agreed access window.
For example, workstation diagnostics may be approved while controller downloads remain excluded.
Record what requires fresh approval, including extra devices or a longer session.
Know who will actually connect.
Identify the engineer, their employer and any subcontractor involved.
Confirm identity through the established supplier contact, not an unexpected message.
A replacement engineer needs reviewed access, not forwarded passwords or shared accounts.
Use one understood access path.
Use the site-approved access service, with a controlled intermediary where required.
Document the route from supplier to the specific authorised target.
Do not expose controller services directly to the internet or improvise another tunnel.
Limit what the session can reach.
Check that the approved route reaches only systems needed for this job.
Access to one workstation should not silently open other production cells.
Have the network engineer review rules, boundaries and documented exceptions.
Keep access tied to a person.
Use individual supplier accounts where the approved technology supports them.
Avoid shared administrator passwords. Assign account ownership and secure credential handling.
Review dormant accounts and remove permissions that no longer have a justified purpose.
Protect the entry point without disturbing control.
Use strong authentication and multifactor authentication at the remote access boundary.
An older controller may not support modern authentication. Record that limitation.
Review compensating controls without unapproved changes to the running control system.
Grant the access the task needs.
Grant permissions for approved diagnostics, not permanent administration.
If elevation becomes necessary, review its reason, duration and expected impact.
Temporary privileges need an owner and a clear withdrawal method.
Review the device joining the session.
Agree supplier endpoint requirements and how the supplier confirms them.
A trusted supplier name does not establish that every laptop is trustworthy.
Do not install remote support software on production equipment without review.
Prepare the session and recovery plan.
Tell operations what happens, when, and who remains available.
For approved changes, check relevant backups, recovery procedures and maintenance arrangements.
Agree stop conditions before troubleshooting begins.
Check the agreement at the start.
At session start, confirm the person, ticket, target and approved window.
Check the access service and required logging are working.
Keep the site contact available, with a clear escalation route.
A changing task needs a new decision.
Keep activity within the approved task. Unexpected requests need a new decision.
If diagnostics become a firmware update or logic change, pause for the required approval.
Record revised scope. The original approval is not unlimited permission.
Treat files as part of the work.
Agree how support files enter or leave, and who reviews them.
Verify provenance and integrity through the approved process; check files before use.
Receiving a file is not approval to deploy it to a controller.
Leave a useful session record.
Retain who connected, why, when, and which systems they accessed.
Link approvals, relevant activity records, changes and results to the support ticket.
Record unsuccessful attempts and unresolved questions, alongside the agreed follow-up owner.
Make records fit together.
Collect relevant gateway and host records through the agreed logging arrangement.
Check time references so tickets and events can be compared.
Record missing logs or timing uncertainty. Do not quietly fill gaps with assumptions.
Agree what recording is appropriate.
Where recording is appropriate, agree scope, access permissions and retention.
Keep passwords and unnecessary sensitive information out of tickets and shared recordings.
A recording supplements approvals and engineering review. It does not replace either.
Observation supports the access controls.
OTCogniShield can add context from traffic presented to its monitoring point.
Passive observation is not the access gateway and does not enforce session approval.
Encrypted sessions can hide application actions. Use access and host records alongside observations.
Prepare emergency access before the fault.
Urgent support needs a predefined emergency process, with a named decision maker.
Record the reason, scope and safeguards. Escalate according to the site procedure.
Emergency access is not the everyday shortcut. Review its use and close it afterwards.
Know how to end access safely.
Agree safe disconnection with operations, including any active engineering work.
End active sessions, revoke session tokens, disable temporary accounts and remove temporary access rules through the approved service.
Check agreed access routes and confirm closure through approved verification.
Return the cell to its agreed state.
Have the engineer confirm the outcome and required operational checks.
Remove temporary access arrangements and update relevant configuration and support records.
Record remaining issues and owners. The ticket should show the final state.
One request. Clear scope. A verified finish.
Before the next support call, record who approves access and its boundaries.
Decide which records you need and how you will end access safely.
Rehearse the process under approved test conditions. Keep the records and improve the gaps.
Thank you.