SSO and Access Provisioning for Remote Assistants

When a company adds remote assistants, IT faces a familiar question with a new twist: how do we give people exactly the access they need, quickly, and take it away just as quickly when they leave? For employees, the answer is usually your identity provider, groups and an onboarding workflow. For remote assistants supplied by a provider, the same answer works best, with a few adjustments.

This guide explains how to provision remote assistants through single sign-on (SSO), keep access least-privilege, and offboard cleanly. It is written for IT and security teams at organizations using an identity provider such as Microsoft Entra ID, Okta, Google Workspace or JumpCloud. For the wider program context, see enterprise security and procurement.

Principle: you own the identities

The single most important design decision is who controls the assistant's identity. If the provider creates and controls accounts, you lose visibility into who has access and depend on the provider to revoke it. If you create the accounts in your own identity provider, you can see every sign-in, enforce your policies and revoke access instantly.

For most organizations, the right model is:

• Accounts created in your identity provider, named for the individual assistant.
• Your password, multi-factor authentication and conditional access policies applied.
• Access to applications granted through SSO and groups.
• Offboarding triggered by you, at any time.

Account type and naming

Decide how assistant accounts are distinguished from employee accounts. Common approaches include a separate user type or attribute (for example, "contractor" or "external"), a naming convention, or a dedicated organizational unit. Distinguishing accounts makes it easier to apply different policies, run access reviews and report on external access. Avoid generic shared accounts such as "assistant1"; every account should map to one person.

Multi-factor authentication

Require multi-factor authentication for every assistant account, preferably with phishing-resistant methods such as FIDO2 security keys or platform passkeys where your environment supports them, or an authenticator app with number matching. Avoid SMS-based codes where possible. If you ship managed devices, you can enroll security keys before shipping.

Conditional access

Conditional access policies let you control how and from where assistants sign in. Useful policies include:

• Require compliant or managed devices for access to sensitive applications.
• Restrict locations to the countries where your assistants work, if that fits your risk model.
• Block legacy authentication protocols.
• Session controls, such as limiting downloads from web applications on unmanaged devices.

Test policies carefully. Overly strict location rules can lock out assistants who travel or whose internet provider's IP addresses geolocate unexpectedly.

Group-based access

Create groups for each assistant role, such as "EA - Finance Leadership" or "AP Assistants," and assign application access to groups rather than individuals. When an assistant joins, adding them to the right group grants the right access. When their role changes, group changes update access consistently. Document what each group grants so access reviews are meaningful.

Least privilege inside applications

SSO controls whether an assistant can sign in; application roles control what they can do once inside. For each application, define the role an assistant needs:

• Email and calendar: delegate access to the executive's mailbox and calendar rather than sharing the executive's credentials. Most platforms support delegated permissions with send-on-behalf rights.
• Finance systems: roles that allow entering transactions but not approving payments or changing bank details.
• CRM: edit access to records, without export or admin rights.
• File storage: access to specific shared folders, not entire drives.

Our least-privilege access checklist covers common applications in more detail, and our guide to shared inbox and calendar permissions covers delegation.

Applications without SSO

Some applications don't support SSO. Options include:

• Named individual accounts with multi-factor authentication, recorded in your access inventory.
• An enterprise password manager with shared vaults for unavoidable shared credentials, giving you logging and the ability to rotate passwords on offboarding.
• Avoiding the application for assistant work if neither is possible.

Never send credentials by email or chat. Our password manager setup guide explains the approach.

The provisioning workflow

A repeatable workflow keeps provisioning fast and consistent:

1. Request: the hiring manager submits a request with the assistant's name, role, start date and required access, referencing the role's group.
2. Approval: the manager and, for sensitive access, the system owner approve.
3. Account creation: IT creates the account with the correct attributes and groups.
4. Credentials and MFA enrollment: delivered securely, with MFA enrollment on the first sign-in or before device shipment.
5. Verification: on day one, the assistant confirms access to each required application; gaps are fixed quickly.
6. Documentation: the access inventory is updated.

Many organizations automate parts of this with their identity provider's lifecycle features or an IT service management tool.

Access reviews

Run access reviews for assistant accounts at least quarterly. The manager confirms each account still needs each group and application. Remove anything unnecessary. Reviews catch the slow accumulation of access that happens when assistants help with "just one more thing."

Offboarding

Offboarding should be same-day and complete:

1. Disable the account in the identity provider, which ends SSO sessions.
2. Revoke active sessions and tokens in key applications.
3. Remove mailbox and calendar delegations.
4. Rotate any shared credentials the assistant could access.
5. Recover or wipe managed devices.
6. Transfer ownership of files and records as needed.
7. Confirm completion in the access inventory.

The provider should notify you immediately when an assistant leaves, and you should be able to act without waiting. Our secure offboarding guide has a full checklist.

Logging and monitoring

Assistant accounts should be included in your normal sign-in and audit log monitoring. Alerts for unusual sign-in locations, impossible travel or mass downloads apply to them just as to employees.

Privileged and high-risk actions

Some actions deserve extra protection even when an assistant legitimately has access: approving payments, changing vendor bank details, granting access to others, exporting large data sets or sending email to external distribution lists on an executive's behalf. Options include:

• Separation of duties: assistants prepare, someone else approves.
• Step-up authentication: require a fresh multi-factor prompt for sensitive actions where the application supports it.
• Approval workflows built into finance and HR systems.
• Alerts on high-risk events, such as forwarding rules created on a mailbox, which are a common sign of account compromise.

Mailbox forwarding deserves special mention. Attackers who compromise an account often create rules that forward mail externally. Block external auto-forwarding by policy and alert on new inbox rules for assistant and executive mailboxes alike.

A worked example

A mid-size company adds three executive assistants and two accounts payable assistants. IT creates an "External - Assistants" user type in its identity provider, with groups for each role. Executive assistant groups grant email, calendar, collaboration tools and the travel booking platform; the AP group grants the AP automation tool in a data-entry role and a specific finance shared folder. Conditional access requires managed devices, which the company ships with security keys enrolled. Mailbox delegations are configured for each executive. On day one, each assistant confirms access in a short checklist call. Quarterly, managers review group memberships. When one assistant moves to a new role, IT changes their group and the old access disappears automatically.

Common mistakes

Provider-controlled accounts. You lose visibility and control.

Sharing executives' passwords. Use delegation instead.

Individual permissions instead of groups. Access drifts and reviews become impossible.

Slow offboarding. Disable accounts the same day.

Frequently asked questions

Can assistants use their own devices?

It depends on your risk model. Options include managed devices or virtual desktops. See managed devices versus BYOD.

Does ExecWing provision accounts for us?

No. We recommend you provision accounts in your own identity system so you retain control. We coordinate timing and day-one checks.

How quickly can we revoke access?

Immediately, if accounts are in your identity provider. We'll also notify you promptly of any departure.

What if an application doesn't support SSO?

Use named accounts with MFA or an enterprise password manager, as described above.