Identity
Review MFA enrollment gaps before a contractor starts
A pre-start check that confirms multi-factor enrollment, recovery methods, and exception expiry for contractor accounts before the first sign-in.
Start with repeatable IT work that has a clear owner, clear access limits, and a review cadence. Keep risky technical decisions with the manager or provider who owns the system.
Delegation playbook
On this pageJump to section
A contractor account can be created correctly and still fail on the first morning because multi-factor enrollment was never completed. The account exists, the group membership is right, and the welcome email is sent, but the sign-in stops at a prompt nobody prepared for. A pre-start review checks enrollment, recovery, and exceptions before the contractor needs access. The review is short and prevents a day-one ticket that delays billable work.
Define the access the role needs
Start from the engagement and the tasks the contractor will perform in the first two weeks. List the applications, folders, and systems required for those tasks and the group that grants each one. Exclude access that might be useful later but is not needed now. A short, specific list is easier to enroll and easier to remove at the end.
Record the authentication method the identity provider expects for each application. Some tools rely on the central identity provider, while others have a separate local login. Note any application that does not support the company's multi-factor standard. That gap needs a decision before the start date rather than an improvised workaround on day one.
Check enrollment before day one
Confirm in the identity provider that the contractor account has at least one strong factor registered. Record the factor type, the enrollment date, and the device or authenticator used. Do not accept a claim that enrollment happened without a matching record. The console is the evidence, not the welcome email.
Ask the contractor to complete enrollment on a managed device or an approved personal device before the start date. Confirm that the device can receive the prompt and that the time is synchronized. If enrollment requires a phone call, schedule it rather than leaving it to the first morning. A five-minute check before the start avoids a two-hour delay.
Test the recovery path
Check that the contractor has a recovery method that does not depend on the same device as the primary factor. Record the recovery email or phone number and confirm that it belongs to the contractor. Test the recovery flow in a controlled way if the provider supports it. A factor that cannot be recovered will become a support incident at the worst moment.
Confirm who can reset the factor and what verification is required before a reset. The service desk should not reset a factor on the strength of a caller's name alone. Record the approved verification method in the contractor's onboarding note. Recovery is part of the access design, not an afterthought.
Record exceptions with an expiry
Some contractors cannot use the standard factor, for example because of a platform limitation or a regulated environment. Record the exception, the reason, and the compensating control in writing. Give the exception an expiry date and a named owner. An exception without an end date becomes a permanent hole in the identity standard.
Review the exception at the halfway point of the engagement and again before the end date. Remove it as soon as the business reason no longer applies. Report open exceptions to the IT manager each month. The count should be small and trending down, not a growing list nobody owns.
Coach the first sign-in
Send the contractor a short guide that covers the first sign-in, the expected prompt, and who to contact if it fails. Include the support hours and the ticket channel rather than a personal phone number. Ask the contractor to confirm a successful sign-in before the first meeting. A confirmed sign-in is better evidence than a read receipt. Record the date the guide was sent so the start-date check has a reference.
During the first week, check whether the contractor has more than one factor registered and whether the recovery details are current. A single factor on a single phone is a fragile setup for someone working remotely. Offer a second factor where the provider supports it. The goal is access that survives a lost device without a security shortcut. Keep the guide short enough that a contractor can read it on a phone before the first call.
Review enrollment monthly
Export the list of accounts without a registered factor and the list with only one factor. Filter for contractors, vendors, and shared accounts. Investigate each account rather than assuming the export is complete. Identity providers sometimes report enrollment from a stale cache, so confirm a sample in the console.
Track the number of contractor accounts without enrollment and the age of the oldest gap. Assign each gap to an owner and a target date. Report the trend to the IT manager beside the contractor headcount. A stable count with a known cause is easier to manage than a sudden increase nobody can explain.
Close the gap at offboarding
At the end of the engagement, disable the account and revoke the registered factors and sessions. Remove the contractor from every group and confirm that the access list is empty. Record the date and the person who performed the removal. A disabled account with an active factor is still a risk if the account is re-enabled later.
Review the offboarding record against the original access list so nothing is missed. Note any exception that was still open and how it was closed. Keep the record with the engagement file rather than in a personal mailbox. The same discipline that made the start predictable makes the exit clean.
Sources and next step
Use the CISA Cross-Sector Cybersecurity Performance Goals and the NIST Cybersecurity Framework 2.0 as primary references for the asset, endpoint, change, physical access, and identity practices discussed in this guide. The NIST patch management planning guidance supports the change handover steps, and NIST digital identity guidance supports the contractor authentication checks. Apply your own policies, contracts, and system documentation to the workflow. Compare this guide with the MFA enrollment review and the spare laptop loaner log before changing a live process.
Keep decisions, approvals, and evidence in systems the business already controls. If the coordination is recurring and your technical owner can define the boundaries, review the IT virtual assistant service areas and contact ITVirtualAssistant to discuss a limited pilot.
Operating brief
What this guide should help you decide
Routine intake, status updates, records, screenshots, and documentation upkeep.
Approvals, risky system changes, security decisions, and final technical judgment.
How to use this guide
Use this page to decide what an IT virtual assistant should handle first. If the task is recurring, documented, and easy to review, it is usually a better first delegation candidate than work that requires live technical judgment.
Treat the article as an operating brief, not just a topic overview. The goal is to turn loose IT work into a named workflow with inputs, outputs, permissions, review cadence, and a handoff rule that protects the business while reducing manager load.
Workflow
Recommended operating workflow
Define the request
Write what review mfa enrollment gaps before a contractor starts means in your company, where requests enter, and what finished work looks like.
Limit the access
Give the assistant only the tool permissions needed for intake, records, status updates, or documentation.
Run a pilot
Use a two-week sample period so the manager can review accuracy before expanding the workflow.
Review patterns
Summarize repeat issues, blocked requests, and escalation volume so the technical owner can improve the process.
Decision rules
| Question | VA fit signal | Escalate when |
|---|---|---|
| Is the work repeatable? | The same request appears weekly and can be described in steps. | The request changes business policy or system design. |
| Can quality be reviewed? | The manager can inspect the output without redoing the work. | Only a senior technical person can judge correctness. |
| Is access contained? | The assistant can work with read-only or role-limited access. | Admin rights, customer data, or security settings are involved. |
Delegation checklist
- Write the intake source, expected output, and manager review cadence.
- Confirm the assistant has only the permissions needed for the workflow.
- List the events that require escalation before work continues.
- Track examples for two weeks before changing the workflow.
- Save examples of good and bad outputs so the assistant has concrete references.
- Review the workflow monthly and remove permissions that are no longer needed.
Example first-week agenda
Day one should cover the workflow owner, tools, allowed actions, forbidden actions, and escalation language. By the end of week one, the assistant should have produced a small sample of completed work, a list of unclear requests, and a manager-reviewed improvement note.
What to review before delegating
Confirm the owner, access level, review cadence, and escalation path before assigning any recurring IT workflow to a remote assistant.
What should an IT virtual assistant handle first?
Start with repeatable, reviewable work such as ticket summaries, account records, documentation updates, and checklist follow up.
Get free IT support review