Do engineers need access to our network?
Yes, inside a segment your IT provides, for the duration of the work, with no path out and nothing left open afterward. Never remote access, a tunnel, or a standing connection.
· 3 min read
IN SHORT
Yes, but only inside a segment the customer's IT provides, for the duration of the work, with no path out and nothing left open afterward. The use case is built on the customer's Czar, so the engineers must reach the appliance to publish versions and read the record. They do not ask for remote access, a tunnel, or a standing connection, and access ends at handoff.
Yes, for a forward-deployed engagement, and only inside a segment the customer's IT provides, for the duration of the work, with no path out and nothing left open afterward. For an in-house project the engineers need access to the appliance to build and to hand off, and the same conditions apply. In neither case does the practice ask for remote access, a tunnel, or a standing connection.
What the access is for
The use case is built on the customer's Czar, not somewhere else and moved in. That is the whole point of the practice: nothing leaves the building, so the building is where the work happens. To publish versions, declare routes, assemble a corpus, and read the run record, an engineer has to reach the appliance.
In a forward-deployed engagement the engineers also sit with the desk and watch the packet arrive, which means being on the floor and on the segment the desk works in. They do not need access to anything beyond that segment, and they do not ask for it.
How IT controls it
IT decides how the access is granted, supervised, and withdrawn. The practice works inside whatever IT chooses: named accounts, a supervised console, a segment with no route to the rest of the network. On an air-gapped site the engineers work on the air-gapped side and nothing they do crosses to any other network, because there is no way for it to.
Everything an engineer publishes goes through Agency under a named role, so the version history shows what they did and when. Integrity verification on the appliance means the version running is the version published. IT does not have to trust the engineers' description of their own work; the record is on the customer's hardware.
What access does not include
Engineers do not take copies off the appliance. They do not connect the appliance to a vendor's cloud or to anything Element 31 operates. They do not keep credentials after handoff. On a connected site they use only the systems the customer already secures, through routes declared in the version and visible to IT, and they add nothing that would need securing after they leave.
When it ends
Access ends at handoff. Closing it is part of the handoff checklist the practice walks through with IT, not something that happens later. If the customer wants the practice back for a next version, access is granted again, under whatever conditions IT sets at that time. It is never a standing arrangement. How the site operates in the meantime is described in what the handoff does not include and working with IT and compliance.
Questions this raises
- Can the engineers work remotely instead?
- No. The practice does not build somewhere else and move the result in, and it does not ask for a tunnel into the site. Forward-deployed engineers are on the floor and inside the segment; project engineers reach the appliance under the same conditions.
- What does IT see of what the engineers do?
- Every version published, under a named role, in the version history; every declared route, in the version; every run, in the record. Integrity verification on the appliance means the running version is the published one.
- What happens to access at the end?
- It is withdrawn as part of the handoff, which the practice walks through with IT. Nothing remains open to the practice. A later engagement means access granted again under whatever conditions IT sets at that time.
KEEP READING