Contractor and Temporary Access

Contractor and temporary access provisioning establishes identity records and system permissions for non-permanent staff with built-in expiry dates and sponsor accountability. This task covers the full lifecycle from initial request through extension or departure, ensuring that external personnel receive appropriate access without the accumulation of orphaned accounts that characterises poorly managed contractor programmes.

The procedures here differ from standard employee onboarding in three fundamental ways: all access carries an explicit expiry date that triggers automatic revocation, a named sponsor within the organisation bears accountability for the contractor’s actions and access appropriateness, and the identity record itself is typed differently to enable reporting and policy differentiation. These distinctions enable organisations to engage external expertise while maintaining the principle that access exists only as long as business need persists.

Prerequisites

Before provisioning contractor access, confirm the following requirements are satisfied:

The sponsor requirement deserves particular attention. A sponsor is a permanent employee who accepts responsibility for a contractor’s access, vouches for ongoing business need, and serves as the point of contact for access reviews and security queries. Sponsors must have sufficient seniority to understand the data and systems the contractor will access. A junior staff member cannot sponsor access to financial systems they themselves lack permission to view.

You will need access to:

• Identity provider administrative console (Entra ID, Okta, Keycloak, or equivalent)
• Access request ticketing system
• Email system for notifications
• Relevant application administrative consoles for application-specific access

Procedure

Determine identity type and access scope

1. Classify the engagement to select the appropriate identity type. Most identity providers distinguish between member (employee) and guest (external) identities. Contractors should receive external identity types unless technical requirements absolutely prevent this.

   For Microsoft Entra ID, create the contractor as a guest user with UserType set to Guest. For Okta, use a contractor-specific user type. For Keycloak, assign the contractor to a realm or group designated for external users.

   Identity Type Selection

   +------------------+     +------------------+     +------------------+
   | Engagement Type  |     | Identity Type    |     | Typical Duration |
   +------------------+     +------------------+     +------------------+
   | Consultant       | --> | Guest/External   | --> | 3-12 months      |
   | Contractor       | --> | Guest/External   | --> | 1-6 months       |
   | Temp agency      | --> | Guest/External   | --> | 1-3 months       |
   | Secondee         | --> | Member/Internal  | --> | 6-24 months      |
   | Intern           | --> | Guest/External   | --> | 1-6 months       |
   +------------------+     +------------------+     +------------------+

Secondees from partner organisations represent a special case. Where a secondee will work as a de facto employee for an extended period and requires deep system integration, a member identity type with contractor flags in metadata may be appropriate. Document the rationale for any deviation from guest identity type.

2. Define the access scope based on the contracted work. Request only the minimum access required for the contractor to fulfil their engagement. A developer contractor needs development environment access but not production. A finance consultant needs read access to reporting but not payment approval rights.

   Create an access matrix for the engagement:

   System	Access Level	Justification	Duration
   Email and calendar	Standard mailbox	Communication with team	Full engagement
   SharePoint	Site member, Finance Project site only	Document collaboration	Full engagement
   Development environment	Developer role	Code development per SOW	Full engagement
   Source control	Write access, assigned repositories	Code commits	Full engagement
   Production systems	None	Not required for development work	N/A

3. Calculate the expiry date. Start with the contract end date, then determine whether any buffer is appropriate. For contractors who may extend, a 7-day buffer after contract end allows time to process extensions without access interruption. For strictly time-bound engagements, set expiry to match contract end exactly.

   Record the calculated expiry:

   • Contract end date: 2024-06-30
   • Buffer period: 7 days
   • Account expiry date: 2024-07-07
   • Access review date: 2024-06-15 (two weeks before contract end)

Create the identity record

1. Create the external identity in your identity provider. The following example uses Microsoft Entra ID via PowerShell, but the principles apply across platforms.

   # Connect to Microsoft Graph
   Connect-MgGraph -Scopes "User.ReadWrite.All"

   # Create the guest user
   $contractor = @{
       displayName = "Alex Chen (Contractor - Acme Consulting)"
       mail = "alex.chen@acmeconsulting.example"
       userPrincipalName = "alex.chen_acmeconsulting.example#EXT#@contoso.onmicrosoft.com"
       userType = "Guest"
       accountEnabled = $true
   }

   $newUser = New-MgUser -BodyParameter $contractor

Include “(Contractor)” or the consulting firm name in the display name. This visual indicator helps staff identify external personnel in address books, meeting invites, and document sharing dialogs.

2. Set the account expiry date. In Entra ID, use the lifecycle workflow feature or set the account expiry directly:

   # Set account to expire on specific date
   $expiryDate = Get-Date "2024-07-07"

   Update-MgUser -UserId $newUser.Id -BodyParameter @{
       extension_contractorExpiry = $expiryDate.ToString("yyyy-MM-dd")
   }

For identity providers without native expiry, create a scheduled task or automation to disable accounts on their expiry date. The mechanism matters less than the guarantee: every contractor account must have an automated expiry that does not depend on manual intervention.

3. Record the sponsor relationship. Store the sponsor’s identity as a custom attribute on the contractor account:

   # Set sponsor attribute
   Update-MgUser -UserId $newUser.Id -BodyParameter @{
       extension_accessSponsor = "sponsor.name@contoso.org"
       extension_sponsorManagerId = "abc123-def456-..."
   }

This linkage enables automated notifications to sponsors before contractor expiry and during access reviews.

4. Assign the contractor to appropriate groups for their access scope. Prefer group-based access assignment over direct permissions; this simplifies later modification and removal.

   # Add to contractor-appropriate groups
   $groups = @(
       "grp-contractors-all",
       "grp-project-phoenix-members",
       "grp-dev-environment-users"
   )

   foreach ($groupName in $groups) {
       $group = Get-MgGroup -Filter "displayName eq '$groupName'"
       New-MgGroupMember -GroupId $group.Id -DirectoryObjectId $newUser.Id
   }

Configure application access

1. Provision email and collaboration access. For Microsoft 365, guest users receive collaboration capabilities through their guest identity without requiring a separate mailbox licence in most configurations. If the contractor requires a full mailbox (rare), assign the appropriate licence.

   Verify the contractor can:

   • Receive email at their external address
   • Access shared Teams channels they are added to
   • View SharePoint sites they are granted access to
   • Join meetings they are invited to

2. Provision application-specific access according to the access matrix. For each application:

                 APPLICATION ACCESS PROVISIONING FLOW

                      +------------------------+
                      |      Access Matrix     |
                      |          Entry         |
                      +-----------+------------+
                                  |
                                  v
                +-----------------+-----------------+
                |           Application             |
                |          Supports SCIM?           |
                +-----------------+-----------------+
                                  |
                  +---------------+---------------+
                  |                               |
                 YES                              NO
                  |                               |
                  v                               v
      +-----------------------+       +-----------------------+
      |    Auto Provision     |       |   Manual Provision    |
      |       via IdP         |       |        in App         |
      +-----------------------+       +-----------------------+

For applications integrated with your identity provider via SCIM or similar, group membership triggers automatic provisioning. For applications requiring manual configuration, complete the provisioning and document the access granted.

3. Configure MFA requirements. Contractors must enrol in multi-factor authentication before accessing organisational resources. External identity types in Entra ID can register their own MFA methods during first sign-in when conditional access policies require MFA.

   Verify that conditional access policies apply to guest users:

   Conditional Access Policy Check:

   Policy: Require MFA for all users
   Users: All users (including guests)
   Applications: All cloud apps
   Grant: Require multi-factor authentication

   Confirm: Guest users are not excluded

4. Apply any data loss prevention or information protection policies appropriate for external users. Contractors may face additional restrictions on downloading, printing, or sharing sensitive documents compared to permanent staff.

Communicate and onboard

1. Send the contractor their access credentials and instructions. Include:

   • How to sign in (identity provider URL or application URLs)
   • MFA enrollment requirements and instructions
   • Expiry date of their access
   • Sponsor contact information
   • Acceptable use policy acknowledgment requirement
   • Support contact for access issues

   Subject: Your access credentials for [Organisation Name]

   Dear [Contractor Name],

   Your access to [Organisation Name] systems has been provisioned for your
   engagement with us. Please find your access details below.

   Sign-in: https://login.example.org
   Username: [their external email]
   Initial access: You will receive a separate email to set up your account

   Your access expires on: [expiry date]
   Your sponsor: [sponsor name and email]

   Before accessing any systems, you must:
   1. Complete MFA enrollment during first sign-in
   2. Acknowledge the acceptable use policy at [link]

   For access issues, contact: servicedesk@example.org

2. Notify the sponsor that contractor access is active:

   Subject: Contractor access activated - [Contractor Name]

   [Sponsor Name],

   Access for [Contractor Name] ([contractor email]) has been provisioned
   as requested. As sponsor, you are responsible for:

   - Confirming ongoing business need for access
   - Responding to access review requests
   - Notifying IT if the contractor departs early
   - Requesting extension if engagement continues past [expiry date]

   Access expires: [expiry date]
   Review reminder: [review date]

3. Record the provisioning in your access management system or ticketing system. Include:

   • Contractor name and external email
   • Identity provider account reference
   • Sponsor name
   • Access granted (systems and levels)
   • Expiry date
   • Contract or SOW reference

Manage access extensions

When a contractor engagement extends beyond the original end date, process the extension before access expires to avoid disruption.

1. Receive extension request from sponsor. The request must include:

   • New contract end date or extension documentation
   • Confirmation that access scope remains appropriate
   • Any changes to required access

   Reject extension requests that lack documentation of continued business need or come from someone other than the designated sponsor.

2. Update the expiry date in the identity provider:

   # Extend contractor access
   $newExpiryDate = Get-Date "2024-12-31"

   Update-MgUser -UserId $contractorId -BodyParameter @{
       extension_contractorExpiry = $newExpiryDate.ToString("yyyy-MM-dd")
       accountEnabled = $true
   }

3. Review and adjust access scope if the contractor’s role has changed. Extension is an opportunity to apply least privilege: remove access to systems no longer needed and add access to newly required systems.

4. Document the extension including the new expiry date, updated access scope, and sponsor reconfirmation.

5. Notify the contractor and sponsor of the extension:

   Subject: Access extended - [Contractor Name]

   Access for [Contractor Name] has been extended.

   Previous expiry: [old date]
   New expiry: [new date]

   Access scope: [unchanged / modified as follows]

   Next review: [new review date]

Process contractor departure

When a contractor’s engagement ends, whether at the planned expiry date or early termination, revoke access promptly and handle data appropriately.

1. For planned departures at expiry, the automated account disable should trigger on the expiry date. Verify that automation executed correctly:

   # Verify account disabled
   $user = Get-MgUser -UserId $contractorId -Property accountEnabled

   if ($user.accountEnabled -eq $true) {
       Write-Warning "Account still enabled after expiry date"
       # Manually disable
       Update-MgUser -UserId $contractorId -BodyParameter @{
           accountEnabled = $false
       }
   }

2. For early departures, disable the account immediately upon notification from the sponsor:

   # Immediate disable for early departure
   Update-MgUser -UserId $contractorId -BodyParameter @{
       accountEnabled = $false
   }

   # Revoke all active sessions
   Revoke-MgUserSignInSession -UserId $contractorId

Early departure may indicate a problem. If the contractor was terminated for cause or left under concerning circumstances, treat this as a potential security event and coordinate with the sponsor and HR before notifying the contractor that access has been revoked.

3. Handle contractor data according to policy. Options include:

   • Transfer to sponsor: Export mailbox, OneDrive, or other personal storage to the sponsor
   • Archive: Move to legal hold or archive if required for compliance
   • Delete: Remove after retention period if no preservation requirement

   For OneDrive content:

   # Grant sponsor access to contractor's OneDrive
   $sponsorEmail = "sponsor@example.org"
   $contractorOneDrive = "https://contoso-my.sharepoint.com/personal/contractor_email"

   # Add sponsor as site collection admin temporarily
   Set-SPOUser -Site $contractorOneDrive -LoginName $sponsorEmail -IsSiteCollectionAdmin $true

4. Revoke application-specific access for applications not governed by identity provider group membership. Check each application in the contractor’s access matrix and confirm removal.

5. Handle third-party devices. If the contractor used their own device under a BYOD arrangement:

   • Remove device from MDM enrollment if applicable
   • Request confirmation that organisational data has been removed
   • Document the device release

   If the contractor used organisation-provided equipment:

   • Retrieve the device
   • Wipe and reimage
   • Update asset inventory

6. Notify relevant parties:

   Subject: Contractor access terminated - [Contractor Name]

   Access for [Contractor Name] has been terminated effective [date].

   Reason: [Engagement completed / Early termination]

   Actions completed:
   - Account disabled
   - Sessions revoked
   - Data handled per policy: [transferred to sponsor / archived / pending deletion]
   - Device: [returned and wiped / BYOD - removal confirmed]

7. Delete the identity record after the retention period. Most organisations retain disabled contractor accounts for 30-90 days to support audit queries and potential re-engagement, then permanently delete.

   # After retention period, delete the account
   Remove-MgUser -UserId $contractorId

Monitor and review contractor access

Ongoing monitoring ensures contractor access remains appropriate throughout the engagement.

1. Configure automated notifications to sponsors before contractor expiry:

   Notification Schedule:

   30 days before expiry: "Contractor [name] access expires in 30 days.
                           Confirm if extension required."

   14 days before expiry: "Contractor [name] access expires in 14 days.
                           Submit extension request or confirm no action needed."

   7 days before expiry:  "Contractor [name] access expires in 7 days.
                           Final reminder - access will be automatically revoked."

   On expiry:             "Contractor [name] access has been revoked.
                           Contact IT if this was unexpected."

2. Include contractors in regular access reviews. When quarterly or annual access recertification occurs, ensure contractors appear in the review with their sponsors as reviewers.

3. Monitor for anomalous contractor activity. Configure alerts for:

   • Access from unexpected locations
   • Access outside expected hours
   • Large data downloads
   • Access to systems outside approved scope

   Contractor accounts warrant additional scrutiny because external parties have less organisational context and accountability.

4. Conduct periodic sponsor reviews. Quarterly, contact sponsors to confirm:

   • Contractor is still engaged
   • Access scope remains appropriate
   • Sponsor is still appropriate (sponsors may leave or change role)

Third-party device considerations

Contractors frequently use devices owned by their consulting firm or themselves rather than organisation-provided equipment. This creates additional security considerations.

For consulting firm devices, establish minimum security requirements in the contract:

• Device encryption enabled
• Current operating system with security updates
• Endpoint protection software installed
• Screen lock configured

Consider requiring MDM enrollment for firm devices that will access sensitive systems. Many consulting firms accept MDM enrollment for their devices when working with security-conscious clients.

For personal devices (BYOD), apply conditional access policies that restrict what data can be accessed from unmanaged devices:

Conditional Access Policy: Contractor BYOD Restrictions

Users: All guest users
Devices: Devices not marked as compliant
Applications: All cloud apps

Session controls:
- App enforced restrictions: Yes
- Block download: Yes
- Require app protection policy: Yes

This configuration allows contractors to view documents in the browser but prevents downloading to unmanaged devices.

For highly sensitive work, require the contractor to use organisation-provided equipment. Provision a laptop from your pool, apply standard security configurations, and recover it at engagement end. The additional cost is justified when the contractor will access confidential data, source code, or systems where a compromise would have significant impact.

+------------------------------------------------------------------------------------------------+
|                                     DEVICE DECISION MATRIX                                     |
+----------------------+--------------------------+-------------------------+--------------------+
|   Data Sensitivity   |       Firm Device        |     Personal Device     |     Org Device     |
+----------------------+--------------------------+-------------------------+--------------------+
|                      |                          |                         |                    |
|   Public /           |  Acceptable with         |  Acceptable with        |                    |
|   Internal           |  security attestation    |  conditional access     |   Not required     |
|                      |                          |                         |                    |
+----------------------+--------------------------+-------------------------+--------------------+
|                      |                          |                         |                    |
|   Confidential       |  Acceptable with         |  View-only access       |                    |
|                      |  MDM enrollment          |  (No downloads)         |   Recommended      |
|                      |                          |                         |                    |
+----------------------+--------------------------+-------------------------+--------------------+
|                      |                          |                         |                    |
|   Highly             |                          |                         |                    |
|   Confidential /     |  MDM required            |  Not permitted          |   Required         |
|   Regulated          |                          |                         |                    |
|                      |                          |                         |                    |
+----------------------+--------------------------+-------------------------+--------------------+

Verification

After provisioning contractor access, verify successful configuration:

Have the contractor confirm they can access each system in their access matrix. Document any access issues and resolve before considering provisioning complete.

Troubleshooting

See also

• Time-Limited Access for conceptual framework governing temporary access
• User Onboarding for standard employee provisioning procedures
• User Offboarding for detailed offboarding procedures applicable when contractors depart
• Third-Party Security Risk for risk assessment framework for external parties
• Access Reviews and Recertification for periodic review procedures that include contractors
• BYOD Policy for policy governing personal device use