A contractor needs one application. How much network access should you give them?

The request says, “Our contractor needs the test application until Friday.” The application happens to run on the same office server as a production database and an administration console. Giving the contractor access to the office subnet would be convenient. It would also answer a much larger question than the one they asked.

Give the contractor only the supported network path and service permissions required for that application, alongside an individual application account. Set an end date, test what is allowed and denied, and assign an owner to remove access.

Write the job down before approving the route: which person, on which device, needs which application, for how long? That sentence becomes the access boundary you can explain and test.

Define the application destination, protocol and port

Consider a hypothetical design contractor reviewing a test portal at 10.42.8.20 over HTTPS on TCP port 443. The same machine also has an administration service, and another host at 10.42.8.30 runs the database. These are private example addresses, not instructions to configure a live deployment.

The job needs the portal. It does not establish a need for the database, an administrative session or every machine in 10.42.8.0/24. Record the hostname, target address, protocol and port. If the portal redirects to a second service, identify that dependency explicitly rather than widening the grant until the login happens to work.

A host route narrows the destination address, but a route alone is not a service permission. The deployment also needs supported policy and firewall enforcement for the intended protocol and port. If the available method cannot express the required restriction, change the deployment plan before inviting the contractor.

Separate device enrollment from access permission

An individually enrolled supported device gives the connection a participant identity. It does not mean that participant should reach every resource in the workspace. Fibmesh Networks uses backend policy as the source of truth; supported endpoint software applies authorized policy locally.

This distinction matches the useful principle in NIST’s Zero Trust Architecture: network location or device ownership alone should not confer trust. It is a design principle, not a certification of any particular deployment.

For a directly enrolled server, evaluate the permitted path between supported devices. For an application on a local area network (LAN) behind a gateway, assess that gateway, the approved resource range, overlap and the reply path. A gateway connection is not a reason to advertise an entire office LAN. An arbitrary router is not automatically a supported Fibmesh gateway.

Confirm the contractor’s actual operating system and supported connection method. Native client behavior and release coverage need verification; a connection that works on one platform does not prove equivalent behavior on another. Compatibility Mode is a limited connection method, with different operating responsibilities from a managed native endpoint.

Keep individual application accounts and HTTPS

Create an individual application account with the role needed for the review. Use test data appropriate for the task. Network access to port 443 cannot decide which customer records the account may view or whether the contractor can change settings.

Keep HTTPS and certificate validation in place. A private path does not remove the need to protect the application session, including any LAN hop between a gateway and the target. Neither network admission nor a recognizable device name replaces application login.

Check dependencies from the application’s point of view. If the portal talks to a database itself, that does not necessarily mean the contractor’s laptop needs a database route. Distinguishing browser traffic from server-to-server traffic often keeps the grant much smaller.

Test permitted and denied contractor access

Use an approved test device to complete the real workflow: resolve the intended name, open the portal, sign in and perform the permitted review action. A connected indicator is only one piece of that test.

Then use an unapproved device or account to check denial. Within the agreed test scope, confirm that the contractor cannot reach the administration service or the separate database. Check application permissions too: a successful login followed by an unauthorized export would still be a failed access design.

Record what was tested, who ran it and the expected outcome. Avoid collecting private keys, tokens or live credentials in the evidence. You need enough detail to repeat the check, not a copy of somebody’s secrets.

Remove contractor access when the work ends

Assign an owner to remove the grant when the work ends. A calendar end date is useful even when the available deployment does not provide automatic expiry; it is not evidence that expiry will happen by itself.

At the end, revoke the application account or role, network permission and any integration credentials issued for the job. Check how active sessions and cached policy behave in the supported release, and verify the former access is denied. Do not assume a saved administrative change instantly terminates every existing connection.

Before adding a second contractor, reuse the worksheet rather than copying a broad profile. The useful reusable arrangement is a clearly defined job, a supported restricted path, an individual application identity and a removal test. That gives the next person access you can justify without inheriting every exception from the last project.