Construction Identity Security: Contractors, Sites, CDEs

A construction or engineering firm can have more external people in its project systems than employees on its payroll, and most of them arrive in a hurry, change roles with each work package and leave without anyone telling IT. Subcontractors, consultants, joint venture partners, agency labour and client representatives all need access to drawings, models, schedules and site systems, often within a day of appointment. Site devices are shared across shifts, plant and survey kit carries its own credentials, and workers on site are identified by cards that can be forged. This guide goes deep on that identity problem: lifecycle for project partners, joint venture tenancy, site workforce identity, shared site devices, common data environment (CDE) access and the machine credentials that link project platforms. It is written for IT, identity and information management teams at contractors, engineering consultancies and their clients. Sector threats, payment fraud and regulation are covered in the Cybersecurity for Construction Guide, which this guide builds on rather than repeats.

Source note: platform behaviour is taken from the vendors' own documentation and UK facts from GOV.UK, Ofqual, CITB and CSCS, as listed under Standards and references; checked in November 2026. Confirm against the official text before relying on it.

Key takeaways

The project, not the company, is the unit of access. Every external identity should be tied to a project and a work package, with a sponsor and an end date, so that access ends when the work does.
Joint ventures need an identity decision at mobilisation. Whose tenant hosts the project, which partner's MFA is trusted and who removes leavers must be agreed before the first drawing is shared.
Site identity is physical and digital at once. Gate access, competence cards and induction records identify people on site; treat card verification and biometric enrolment with the same care as an account.
Shared site devices need individual sign-in. Tablets in the cabin and on the slab should know who is using them, so that a signed inspection or a released permit traces to a person.
Project integrations are non-human identities with expiry dates. API keys and service accounts linking the CDE, scheduling, cost and survey platforms must be inventoried per project and revoked at closure.

Who needs access, and from where

Inventory identity populations per project, not only per company. The table shows the usual groups and where their identity should come from.

Population	Systems they use	Where identity should come from	Typical lifetime
Direct staff (site managers, engineers, quantity surveyors)	Email, CDE, ERP, scheduling, site tablets	Own HR and identity provider	Years, but moving between projects
Consultants and designers	CDE, model coordination, collaboration sites	Their own organisation's identity provider, federated as guests	Design stages, often months
Subcontractors	CDE (their work package), permits, quality and snagging apps	Their organisation where it has one; otherwise a governed guest with one-time passcode or a local account	Weeks to months
Agency and labour-only operatives	Site access, inductions, sometimes timesheet apps	Site access system, linked to verified competence card	Days to weeks
Joint venture partner staff	Everything on the project	Partner identity provider via cross-tenant trust	Life of the JV
Client and employer's agent	CDE review areas, reporting	Client identity provider as guests	Life of the project and handover
Devices and integrations	Site tablets, cameras, gate controllers, telematics, platform APIs	Device management and a secrets manager	Project duration, then revoked

Two principles follow. First, prefer federation over local accounts: a consultant who leaves their firm should lose access to your CDE when their home account is disabled. Second, where a small subcontractor has no identity provider, give each person a named, governed guest account, never a shared "subbie" login. See the Contractor Identity Lifecycle Guide for the general model.

Contractor churn: lifecycle by work package

The live construction guide recommends sponsored, expiring guest identities. The detail below makes that workable at the scale of a large project.

Stage	Trigger	Identity action	Owner
Appointment	Subcontract or appointment signed	Create a project access package per work package (CDE folders, apps, site systems) with an end date matching the programme	Project information manager
Request	Partner names its people	Partner's nominated sponsor requests or approves access for their own staff; your project manager approves the package	Partner sponsor and project manager
Mobilisation	First day on project	Guest account delivered, MFA registered, site induction linked to the identity	Site administration
Change	New work package or role	New package assigned, old one removed, never accumulated	Project manager
Review	Monthly, and at each stage gate	Sponsor confirms each person still needs access	Partner sponsor
Exit	Package complete, subcontract ends, or person leaves partner	Assignment expires or is removed; account blocked, then deleted	Automated, checked by IT

Identity governance tools implement this directly. In Microsoft Entra entitlement management, for example, a connected organisation represents a partner, an access package policy for identities not in your directory lets that partner's users request access, and the guidance recommends making partner staff sponsors and approvers because they know who needs access. Packages carry an expiry (Microsoft's example is 180 days), and when an external user loses their last assignment the default is to block sign-in and delete the guest account after 30 days; setting the days to zero removes it immediately. Entitlement management only removes guests it invited or that were converted to governed, so legacy guests from before the rollout need a one-off clean-up. Also set "Guests can invite" to No, so that partners cannot extend access themselves. See the Entra ID Entitlement Management and Access Packages Guide and How to audit guest and external users.

Project closure is the leaver event that nobody owns

At practical completion dozens of partner identities should lose access at once, yet project teams have moved on. Make closure a checklist item with sign-off: all project packages expired, CDE external sharing links revoked, partner devices removed from management, site access cards deactivated, integration credentials revoked, and the retained archive restricted to named staff. The Building Safety Act golden thread guidance for higher-risk buildings expects information to be "secure from unauthorised access" and for handover to include "access and control of the building information", so transfer administrator rights for the CDE space and building systems to the client or accountable person on a recorded date rather than leaving contractor admins in place.

Joint ventures and cross-tenant access

JVs pose a choice that the live guide introduces: host the project in one partner's tenant with guest access for the others, or create a separate JV tenant. Whichever model you choose, these identity settings decide whether it is secure.

Trust partner MFA deliberately: in Entra cross-tenant access settings, inbound trust settings decide whether your Conditional Access accepts MFA, compliant device and hybrid joined device claims from a partner tenant. By default these claims are not trusted, which means partner users register MFA again in your tenant. Trusting MFA from a partner with phishing-resistant methods reduces friction; trusting a partner with weak MFA imports their weakness.
Use organisational settings per partner: organisational settings override defaults, so configure each JV partner explicitly and restrict default B2B collaboration for everyone else. Trust settings require Entra ID P1 on the configured tenant.
Agree leaver responsibility in the JV agreement: each partner must disable departing staff within an agreed time, and the host tenant reviews partner groups monthly.
Plan the JV tenant's end: a separate tenant needs its own break-glass accounts, administrators from more than one partner, and a dated decommissioning plan with archive export.

See the Entra ID Cross-Tenant Access and B2B Guest Governance Guide.

Site workforce identity

On site, the identity that matters first is "is this the trained, inducted person they claim to be". That is an identity proofing problem.

Verify competence cards electronically: in the UK, the CSCS Smart Check app was launched in April 2022 to meet a Construction Leadership Council requirement for a smart way to validate cards carrying the CSCS logo, and Ofqual and CITB stated in November 2025 that it verifies all 2.3 million CSCS-logoed cards. Visual inspection of a plastic card is not verification.
Know the fraud picture: the same Ofqual, CITB and CSCS survey (473 responses, 17 to 31 October 2025) found that 78% of respondents did not know the process for reporting suspected qualification fraud, and noted that fraudulent qualifications can be used to obtain cards that let people onto sites. Give site managers a clear reporting route.
Bind site access to the verified identity: enrol gate or turnstile credentials only after card verification and induction, and deactivate them automatically when the person's subcontractor package ends. See the Physical Access Control Systems Security Guide.
Handle biometrics as special category data: fingerprint or face recognition at gates processes biometric data for unique identification, which is special category data under UK and EU GDPR Article 9. Complete a data protection impact assessment, offer an alternative where required, and set deletion at project end.
Executive and finance identity: payment instructions are identity claims. The Arup deepfake fraud, in which a finance worker in the engineering firm's Hong Kong office was persuaded by a deepfaked video call to make transfers totalling HK$200 million, shows that a familiar face is not authentication. Verify through a pre-registered channel and require a second approver.

Shared site devices and plant credentials

Cabin PCs, rugged tablets on the slab and kit in the site van are shared across shifts and trades. Individual accountability matters because the device is used to sign inspections, close snags, issue permits to work and record quality checks.

Shared device sign-in: enrol tablets in device management and use a shared-device mode with fast individual sign-in and one-step sign-out. Microsoft Entra shared device mode, for example, lets a worker sign in once to supported apps on iOS, iPadOS or Android and sign out of all of them at the end of a shift. See the Passwordless for Frontline and Shared Devices Guide and the Mobile Device Management Security Guide.
Plant and survey kit: telematics portals, machine control base stations, total station controllers and drone fleet accounts often have one login per site or per firm. Where the platform supports named users, use them; where hardware forces a shared credential, change the default, store it in a vault with check-out, and rotate when anyone who knew it leaves.
Site cameras, gates and temporary building systems: each device credential is a non-human identity. Record it in the project asset list with an owner, change defaults at install, and rotate at handover. See the Device and IoT Identity Guide.
Vendor support for site systems: broker remote support through a recorded, approved session rather than a standing vendor login. See the OT Remote Access Guide.

Project platform access

The CDE is the system of record for design and construction information, and its permission model is where most over-sharing happens.

Single sign-on for everyone who can have it: connect the CDE and model coordination platforms to your identity provider, so partner guests and staff sign in with MFA and Conditional Access, and disabling an account removes platform access.
Folder and role design by work package: partners see their work package and the shared information they need, with sensitive areas (security layouts, critical plant, resident data) restricted further according to the project's ISO 19650-5 sensitivity assessment.
Project administrator roles: keep CDE project admin rights to a small number of named staff, review them at each stage gate, and log changes to permissions.
External sharing links: prefer authenticated sharing to anonymous links, set expiry on any link that must exist, and include links in the closure checklist.
Download and export monitoring: alert on bulk downloads of model and drawing sets, particularly by partners near the end of their package.

Where non-human identities fit

Construction platforms are stitched together with integration credentials: CDE to scheduling, cost management to ERP, drone survey uploads, document control to email, and site sensors to dashboards. Many are set up by a project team under deadline and never reviewed. Treat each as a project-scoped non-human identity:

Register it in the project asset list with platform, purpose, permission scope and owner.
Scope it to the project, never to the whole company account on the platform.
Store it in a secrets manager, not in a shared spreadsheet or the site cabin's notebook.
Expire it at project closure, with the revocation recorded on the closure checklist.

See the API Key Management Guide.

Rolling it out

Weeks 1 to 4, count: list every live project's external users, shared accounts, site devices, plant platform logins and integration credentials; identify legacy guests with no sponsor.
Weeks 4 to 12, pilot on one new project: access packages per work package with partner sponsors and expiry, SSO for the CDE, and individual sign-in on site tablets. Keep the previous manual process running in parallel until the first monthly review completes.
Months 3 to 6, clean up live projects: sponsor attestation for every existing guest, removal of those not confirmed, and replacement of shared subcontractor logins with named accounts.
Months 6 to 9, site identity: electronic card verification at every gate, site access deactivation linked to package expiry, and a biometric DPIA where biometrics are used.
Ongoing: closure checklist enforced at practical completion; JV identity terms in every new JV agreement.
Rollback: apply new guest policies to new projects first and to live projects by group, so a failing configuration can be reverted for one project without stopping others, and keep a monitored break-glass account.

Small firms and large contractors

Small firm or specialist subcontractor: MFA on email and the CDE for everyone, named accounts for every person, a per-project spreadsheet of external users reviewed monthly, and a password manager for unavoidable plant logins.
Tier 1 contractor or JV: identity governance with access packages and sponsor attestation, cross-tenant trust settings per partner, SSO on every project platform, electronic card verification integrated with site access, and a central register of project integration credentials.

Detection and measurement

Identity provider: guest sign-ins after package expiry attempts, new guests invited outside access packages, MFA registration from unusual locations, and partner accounts dormant for 30 days.
CDE: bulk downloads, permission changes by project admins, and anonymous link creation.
Site: gate access by credentials linked to expired packages, and card verification failures.
Integrations: project API keys used after closure or from unexpected networks.

Metric	Target direction
External accounts with a sponsor, a project and an end date	100 percent
External accounts active past their package end date	Zero
Days from practical completion to revocation of all partner access	Falling, target under 7
Shared logins remaining on project platforms and site devices	Falling to documented exceptions
Gates using electronic card verification	100 percent of sites
Project integration credentials revoked at closure	100 percent

Framework mapping

Control area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	Threat addressed (ATT&CK v20)
Partner lifecycle by work package	PR.AA-01, PR.AA-05	AC-2, PS-7	T1078 Valid Accounts
JV cross-tenant trust	GV.SC-07, PR.AA-03	AC-20, IA-8	T1199 Trusted Relationship
Project closure revocation	GV.SC-10	PS-7, AC-2	T1078 Valid Accounts
Site workforce verification and access	PR.AA-02, PR.AA-06	IA-12, PE-2, PE-3	Physical intrusion (no ATT&CK technique)
Shared site devices	PR.AA-01	IA-2, IA-4	T1078 Valid Accounts
CDE permissions	PR.AA-05	AC-3, AC-6	T1213 Data from Information Repositories
Payment instruction verification	PR.AA-02	IA-12	T1657 Financial Theft, T1534 Internal Spearphishing

Common failure patterns

One login per subcontractor: the whole firm shares an account on the CDE or permits app, so nobody can say who released a drawing or closed an inspection.
Guests that never expire: partner accounts from finished projects still active years later, often with access to live projects through broad groups.
JV partner MFA trusted without checking: inbound trust accepts MFA claims from a partner whose methods are weaker than your own.
Visual card checks only: fraudulently obtained or forged cards admitted to site because nobody verifies them electronically.
Contractor admins left in place after handover: the client inherits a CDE space and building systems whose administrators still work for the contractor.
Payment instructions accepted on sight or sound: a convincing call or video treated as proof of identity, as in the Arup deepfake fraud.

Practitioner checklist

Inventory identity populations per project, with source of identity and end date.
Create access packages per work package with partner sponsors, approvals and expiry.
Set guest lifecycle to block and delete after the last assignment ends, and stop guests inviting guests.
Configure cross-tenant trust per JV partner deliberately, and write leaver duties into JV agreements.
Verify competence cards electronically and link site access to package expiry.
Give shared site devices individual sign-in, and vault any unavoidable shared plant credential.
Put the CDE behind SSO, design folders by work package, and limit project admin rights.
Register, scope and expire every project integration credential.
Run a closure checklist at practical completion and transfer admin rights at handover.

Construction Identity Security: Contractor Churn, Site Devices and Project Platform Access