Who Gets In and Who Gets Cut Off: A Field-to-Office Access Review for Connected Jobsite Deployments

The Access Problem Is Operational, Not Just Technical

When a general contractor deploys a connected jobsite platform, the immediate conversations tend to center on features: field data capture, RFI workflows, daily logs, drawing distribution. Access governance gets treated as a configuration task to finish before go-live. That sequencing is backward. Identity and access decisions made at deployment shape every subsequent workflow, audit trail, and incident response for the life of the project.

This review is not about threat modeling or security theater. It is about the practical question every construction IT leader and project executive faces: at any given moment, do you know who has access to your project data, from which devices, at what permission level, and what happens when that person leaves the job?

---

Identity: The Foundation That Erodes With Turnover

Construction projects run on rotating labor. A subcontractor crew foreman who needs full drawing access in month two may be off the project entirely by month four. If your connected platform provisions access by role or company rather than by named individual with an expiration trigger, you will accumulate stale accounts that no one actively manages.

The operational fix is not complicated, but it requires a policy commitment before deployment. Each account should be tied to a named individual with a defined project affiliation and an access end date linked to that affiliation. On projects using a common data environment or project controls platform, the provisioning workflow should require the subcontract administrator or project manager to initiate access, not self-service sign-up by the subcontractor's own IT team.

Single sign-on federated through a central directory reduces provisioning drift, but most specialty contractors do not operate a corporate identity provider. For those firms, the GC's platform becomes the identity authority by default. That means the GC's IT team or project controls lead carries the deprovisioning burden. Assign it explicitly in the project technology plan.

---

Subcontractor Turnover: The Access Gap No One Closes

Subcontractor workforce turnover mid-project creates a category of access exposure that is easy to overlook because it happens at the crew level rather than the company level. A subcontractor firm retains its organizational access even after the individual who configured that access has left. If the platform grants access to a company account that then delegates internally, the GC has no visibility into who at that firm is actually logging in.

The practical control here is individual-level provisioning with a named sponsor inside the subcontractor organization who is accountable for their firm's user list. That sponsor relationship should be documented in the subcontract or technology exhibit, not just in platform settings. When a subcontractor demobilizes a trade, the sponsor's obligation to submit a deprovisioning list within a defined window should be enforceable.

---

Device Custody: Shared Tablets and Forgotten Phones

Field deployments frequently rely on shared devices: tablets mounted in site trailers, phones checked out from a field office, kiosks at the entrance for daily safety acknowledgments. Shared devices create session persistence problems. A worker who logs into a field platform on a shared tablet and does not log out leaves an authenticated session that the next user can exploit, even unintentionally.

The minimum viable control for shared devices is session timeout configured at the platform level, set short enough to force re-authentication between users. For platforms that cache project data locally for offline use, shared devices also create a local data exposure: drawings, specifications, and submittals sitting in an app cache accessible without authentication if the device is unlocked.

Device management policy should define which device categories are permitted, whether platform data can persist locally, and what remote wipe capability exists if a device is lost. These decisions belong in the deployment plan, not in a post-incident response.

---

Offline Work: The Sync Gap Creates a Governance Blind Spot

Connected jobsite platforms almost universally support offline mode because field connectivity is unreliable. Offline capability is genuinely useful. It also creates a period during which work performed on a device is not yet reflected in the system of record, audit logs are incomplete, and any access revocation that occurred during the offline window has not yet taken effect on the device.

If an account is deprovisioned while a device is offline, the user retains functional access to whatever data is cached locally until the device syncs. Depending on how the platform handles sync conflicts, a deprovisioned user's offline work may also write into the project record on reconnection.

Platform administrators should understand exactly what their vendor's offline behavior is for both data access and deprovisioning. Document it. Where the behavior creates an unacceptable window, the operational control is shortening the permitted offline period through connectivity requirements or scheduled sync enforcement.

---

Least Privilege: Permission Levels Drift Toward Permissiveness

Most connected jobsite platforms offer role-based permission structures with meaningful granularity: view-only, markup, submit, approve, admin. In practice, projects tend to set permissions once at deployment and then respond to individual complaints by escalating access rather than reviewing whether the original configuration was right.

Least privilege means each user has the minimum access required to do their job on this project at this phase. A subcontractor's project manager does not need to see another trade's RFI log. An owner's representative may need read access to drawing revisions but not to cost data. A foreman needs current-revision drawings for their scope, not global document control.

Schedule a permission review at major project phase transitions: mobilization, structure complete, MEP rough-in, close-out. A brief audit at each transition costs less time than managing the downstream consequences of over-provisioned access.

---

Incident Ownership: Who Calls It and Who Fixes It

When an access incident occurs, such as an account logging in after a subcontractor demobilized, or a device with cached project data being reported stolen, the response often stalls because ownership is ambiguous. Is it the GC's IT team? The project manager? The subcontractor? The platform vendor's support desk?

Define incident ownership in the project technology plan before go-live. The plan should name a primary contact for access incidents, a secondary if the primary is unavailable, the expected response window, and the communication path to the project executive and owner if the incident involves sensitive cost or contract data. Vendors can support investigation, but they should not be the de facto decision-makers about what constitutes an incident or what remediation is appropriate.

---

Predeployment Access Checklist

Before a connected jobsite platform goes live on a project, confirm the following:

• Individual accounts required for all users; no shared credentials
• Access end dates set and linked to project affiliation
• Named provisioning sponsor identified for each subcontractor firm
• Deprovisioning obligation documented in subcontract or technology exhibit
• Session timeout configured on all shared devices
• Local data caching policy defined and communicated
• Remote wipe capability confirmed for all enrolled devices
• Offline sync behavior documented for deprovisioning edge cases
• Permission levels reviewed against project roles, not defaulted to maximum
• Phase-transition permission review dates scheduled
• Incident ownership and response path named in writing

None of these controls require advanced security tooling. They require policy decisions made before deployment rather than after the first gap surfaces.