A shop-floor fat client speaks a proprietary TCP port with no login or redirect, so any host that reaches the port is served - where can a per-user decision live, and what will it still not cover?
answer
- nowhere in the protocol to put a credential
- the decision moves under the application
- connection-level, never action-level
- every device that cannot run an agent
- a self-asserted name is not proof
basics
~20 sNot in the protocol - it moves to the transport: a per-user, mutually authenticated tunnel terminating on the app host, with the app on loopback behind it. That decides who may connect, never which action they may perform.
solid answer
~50 sAn identity-aware front door needs somewhere in the conversation to carry a credential - a header, a redirect, a session. A proprietary binary protocol has none of those, so nothing you place in front of it can parse or challenge it; it can only pass bytes. The workable placement is the transport: a per-user, mutually authenticated tunnel from an agent on the operator workstation to a terminator on the application host, with the application bound to loopback behind it. That gives you a real user and device identity and a record of who connected. What it does not give you is granularity: the enforceable decision is *this user, on this device, may open a connection to this port*, not *may release this batch*. The application's own actions stay unauthorised and unattributed, and every device you cannot install an agent on - a vendor laptop, a hardened panel, an appliance - becomes a permanent exception.
go deeper
Know that an identity front door needs a place in the protocol to carry a credential, and that many older client-server protocols simply have none.
Explain the transport-level placement: a mutually authenticated per-user tunnel terminating on the app host with the app on loopback, and why the client is unaware of it.
Demonstrate that you state the residual precisely - connection granularity, no action-level audit, the agentless exception list - rather than claiming the application is now protected.
Own the decision about how long the estate carries an application whose access control can only ever be connection-shaped, and what evidence you owe a customer or an auditor meanwhile.
### Why the obvious answer fails The reflex answer is to front the application the way you would front a web application. That answer assumes something the protocol does not provide: a **place to carry a credential**. A binary client-server protocol invented for a plant floor has no authorization header, no redirect to an identity provider, no cookie, and frequently no notion of a session at all - the client opens a socket and starts sending records. An intermediary that cannot parse it cannot challenge it, cannot reject one request while allowing another, and cannot attribute anything inside the stream. It can only decide whether the socket opens. Saying this out loud is most of the answer. The second most common miss is *just require mutual TLS* - the client is a compiled binary that does not speak TLS and cannot be changed, so the TLS has to happen somewhere the client is not aware of. ### Where the decision can actually live **1. In the transport, under the application.** An agent on the operator's workstation authenticates the human and the device and establishes a mutually authenticated tunnel to a terminator on the application host; the application is bound to loopback behind it. The fat client keeps talking plain TCP to what it thinks is the server. This is the placement that works today with no application change, and it is the one to lead with. **2. In the application, by changing it.** A rewrite or a supported vendor release that carries a token and authorises per action. This is the only option that ends up with a user name attached to each action rather than to each connection - and it costs a year or more, if the vendor still exists. **3. Nowhere, deliberately.** Keep the protocol reachable only from a small, named set of source hosts, record the sessions on those hosts, and control who may sit at them. This is an administrative control wearing a network costume, and it is a legitimate answer when the population is genuinely small and the alternative is unfunded. ### What the transport-level decision does not cover - **Action granularity.** *May connect* is the only verb available. Reading a work order and releasing a production batch are the same decision to an enforcement point that cannot read the protocol. - **Attribution inside the session.** The application logs, if any, name the tunnel terminator. The user exists only in the tunnel's connection record, so the finest statement you can defend afterwards is *this person had a connection open during that window*. - **Devices that cannot run an agent.** A machine builder's laptop, a locked-down operator panel, a test rig, an appliance. Each becomes an exception with a source-address allowance, and exceptions with no expiry accumulate until they are the policy. - **Machine callers.** The nightly integration has no human to authenticate; it needs a device or service identity, and giving it one means a credential that sits on a server and is worth stealing. - **Anything already on the application host.** The terminator and the application share a machine, so local code execution there bypasses the whole arrangement. ### Getting the direction of the claims right A tunnel that authenticated a user proves a credential and a device key were accepted at connection time. It does not prove the person is still at the keyboard, and it says nothing about what flowed inside. If someone later offers to add a *username* field to the proprietary protocol so the server can log it, notice what that buys: unless the server verifies the name against an authority, a self-asserted field is a claim, and any caller who can reach the port can set it. It improves the log for honest users and stops no adversary. ### How to present the residual The honest sentence for a steering group or an auditor is narrow and defensible: *access to this application now requires an authenticated user on an enrolled device, and we can show who held a connection and when; we cannot show what they did inside it, and there is an exception list of N devices we could not enrol.* That sentence is worth more than a claim of coverage you cannot support, and it is the sentence that eventually funds the rewrite.
- Why is a transport-level decision weaker than one the application makes itself?Because its vocabulary is a connection. It can say who may open a socket to a port, but the application's operations are opaque to it, so there is no per-action authorisation and no per-action audit. Everything a user does inside an approved connection is undifferentiated, which matters most for exactly the operations you would want a second check on.
- The vendor offers to add a username field to the protocol next year - does that solve it?Only if the server verifies that name against an authority and refuses connections that fail. A field the server reads and trusts is self-asserted: any caller who reaches the port sets it to whatever it likes. It improves logging for legitimate users and changes nothing for an adversary, so do not let it be presented as authentication.
- How do you keep the agentless exception list from becoming permanent?Give each entry an owner, an expiry and a named compensating measure - a restricted source host, session recording, or a supervised bay - and re-sign them on a schedule. Count them and report the count, because the number is the honest measure of how much of the estate the control does not cover.
You can put a receptionist in front of an office door. You cannot put one in front of a sealed pneumatic tube - the tube has no place to write a name on.
saying these in an interview costs you the question
- Assumes any identity-aware front door can parse any TCP protocol
- Calls a connection-level allow a per-request authorization
- Proposes mutual TLS on a client that cannot speak TLS
- Ignores the workstations and panels that cannot run an agent
- Believes a self-asserted username in the protocol is authentication