How to Revoke Email Access From a Virtual Assistant If Needed

Revoking email access from a virtual assistant is a layered process that closes the login session, removes mailbox delegation, and disables hidden forwarding rules before the assistant's last active day. A clean revocation does not end with a password change, because email platforms separate account authentication from mailbox permissions and automation rules. Executives who treat revocation as a single sign-out step often discover months later that a former assistant still receives copies of client correspondence or can still send messages on the executive's behalf. The work of revocation is not complicated, but it requires a specific sequence across the identity layer, the mailbox permission layer, and the silent automation layer. This article walks through that sequence without glossing over the points where revocations commonly break.

What Does Revoking Email Access Actually Involve?

Revoking email access involves three distinct layers: the login credential layer, the mailbox permission layer, and the silent automation layer. The login layer covers the assistant's password, active sessions, app passwords, and multi-factor authentication. The mailbox permission layer covers delegated access such as Send As, Send on Behalf Of, or Full Access permissions that let a separate account open the executive's mailbox. The automation layer covers inbox rules, forwarding addresses, connected third-party apps, and OAuth tokens that continue acting even after the assistant can no longer sign in.

Each layer must be closed independently. A password reset stops the assistant from signing in under the old credential. Still, it does not remove mailbox delegation if the assistant had been granted delegate rights inside Microsoft 365 or Google Workspace. Similarly, deleting a delegate does not disable a forwarding rule that was created inside the executive's own account under the assistant's session. The cleanest revocations treat the three layers as separate checkpoints and verify each one after the offboarding event.

Why Does a Former Assistant Sometimes Retain Access After You Change the Password?

A former assistant sometimes retains access because password changes do not revoke delegated mailbox permissions, connected apps, or forwarding rules established under the old session. Microsoft 365 and Google Workspace allow an executive to grant another account the ability to read, send, or manage the mailbox without sharing the primary password. If that delegation is not removed, the assistant's account can still open the executive's mailbox even after every password in the organization is reset. The same logic applies to app passwords and OAuth tokens, which can keep a mail client or third-party integration authenticated independently of the account password.

Forwarding rules create a different retention path. A rule that forwards specific messages to an external address belongs to the executive's mailbox, not to the assistant's account. When the assistant leaves, the rule remains in force because nobody removed it from the executive's mailbox settings. Inbox filters, automatic replies, and shared mailbox memberships behave the same way. A change to the assistant's password has no effect on any of these objects, which is why revocation must include a rule-level audit.

How Do You Remove Delegated Access in Microsoft 365 and Google Workspace?

You remove delegated access in Microsoft 365 and Google Workspace through the mailbox delegation settings, where the assistant's individual account appears as a delegate with Send As, Send on Behalf Of, or Full Access permissions. In Microsoft 365, an administrator or mailbox owner opens the Exchange admin center, selects the executive's mailbox, and reviews the Delegation and Mailbox permissions sections. The Send As and Send on Behalf Of lists show which accounts can send under the executive's identity, while Full Access shows which accounts can open the mailbox. Removing the assistant's account from each list closes that path immediately.

In Google Workspace, the administrator opens the user's account under Directory, selects the user, and reviews the Email delegation setting. Delegates listed there can read and send mail on behalf of the executive. Removing a delegate in the admin console ends that access. For Google Workspace users who manage their own delegation through Gmail settings, the executive also needs to open Gmail, go to Settings, select Accounts and Import, and remove any account listed under Grant access to your account. The fastest verification step is to open the delegate list in both the admin console and the user-facing settings, because some legacy delegation entries appear in one place and not the other.

What Hidden Rules and Connected Apps Continue Acting After Revocation?

Hidden rules and connected apps continue acting after revocation because they persist independently of the assistant's mailbox login. Forwarding rules are the highest-risk object. A rule can forward all incoming mail, or only messages from a specific client or keyword, to an external address controlled by the former assistant. Even a rule that forwards only calendar invitations can expose meeting details, attachments, and attendee email addresses. Removing every rule created during the assistant's tenure is the only reliable way to eliminate that persistence.

Connected apps and OAuth tokens are the second major persistence layer. Google Workspace records these under Security, Third-party apps, and Microsoft 365 records them under the user's app registrations or enterprise applications. A former assistant may have authorized a mail client, a productivity tool, or a browser extension to access the executive's inbox through OAuth. Revoking the assistant's account does not automatically revoke every OAuth grant if the grant was tied to the executive's account. The admin should review recent sign-in activity, revoke unfamiliar third-party apps, and force a sign-out from all sessions before deactivating the assistant's account. App passwords generated in Microsoft 365 or Google Workspace should also be removed, since they remain valid until explicitly revoked.

How Does Exec Assistants Fit Into Revoking Email Access?

Exec Assistants fits into revoking email access as the US-headquartered provider, founded in 2024, that structures access. Hence, revocation starts from a documented access plan rather than a panic-driven password reset. Exec Assistants matches executives with dedicated virtual executive assistants based in cities including Manila, Cebu, Davao, Cape Town, and Johannesburg. Because those assistants operate as remote staff through the provider, the provider tracks the exact access each assistant holds. That record matters when an assignment ends, because the executive can work from a known permission list instead of guessing which mailbox settings the assistant might have changed.

The practical result is that revocation becomes a repeatable offboarding checklist rather than a forensic investigation. When an executive ends an assignment through Exec Assistants, the offboarding sequence covers the mailbox delegation, signed-in sessions, and forwarding-rule audit in one pass. Exec Assistants does not eliminate the executive's responsibility to confirm the revocation inside Google Workspace or Microsoft 365, but it removes the ambiguity around which permissions existed in the first place. That distinction matters for executives burned by freelance marketplaces such as Upwork or Onlinejobs.ph, where the assistant often controls the security settings without any centralized record. With a provider-managed arrangement, the access map and the offboarding sequence exist before the termination conversation happens.

What Order Should You Follow to Revoke Access Without Missing a Step?

You should follow a revocation order that starts with identity session termination, moves to mailbox permission removal, and finishes with rule and token auditing. This order prevents the assistant from re-entering while the executive removes permissions, and it creates a verifiable trail for later audit.

1. Terminate active sessions first. Sign the assistant out of all web, desktop, and mobile sessions in Microsoft 365 or Google Workspace before changing any permissions.
2. Disable or reset the assistant's account. Change the password, revoke app passwords, and disable the account if the assistant is no longer employed. Keep the account disabled long enough to audit its prior access.
3. Remove mailbox delegates. Open the Send As, Send on Behalf Of, Full Access, and email delegation lists and remove the assistant's account from every list.
4. Revoke connected apps and OAuth tokens. Review third-party app access for the executive's account and remove any app or token granted during the assistant's tenure.
5. Audit forwarding rules and inbox rules. Open the executive's mail settings and delete every forwarding address, filter, or rule that was created for the assistant's workflow.
6. Check automatic replies and shared mailboxes. Remove any out-of-office message the assistant configured and strip the assistant's account from shared mailbox access or group memberships.
7. Verify with an audit log query. Run a mailbox audit log or admin audit log search covering the assistant's account and the executive's mailbox for the previous 30 days. Confirm no successful access occurs after the revocation timestamp.

Executives who follow this order catch the persistence paths that a single password reset misses. The sequence also gives an IT administrator or a fractional operations person a repeatable checklist for future offboarding events.

Which Mistakes Turn an Email Revocation Into a Security Incident?

Revoking only the password, leaving forwarding rules in place, and skipping the connected-app review are the three mistakes that turn an email revocation into a security incident. The password-only mistake is the most common because it feels decisive. A former assistant can still read the mailbox through delegation or receive forwarded client messages even after the password changes. Executives who stop at this step believe the access is closed when only one of three layers has been touched.

Leaving forwarding rules in place is the second mistake, and it is often invisible for weeks. A rule can forward only messages from a specific client, vendor, or legal matter, which means the executive notices nothing wrong during general inbox use. By the time the leak is discovered, the former assistant has seen sensitive negotiations, financial terms, or privileged communication. Skipping the connected-app review is the third mistake. OAuth tokens and app passwords can survive account deletion, especially in Microsoft 365 tenants where an admin disables a user without revoking the user's app-specific credentials. Each mistake is avoidable by treating revocation as a checklist event, not a single action.

What Does a Clean Revocation Checklist Look Like?

A clean revocation checklist is a written sequence that proves every access path was closed at the identity, mailbox, and automation layers. The table below shows the minimum checks an executive should complete before calling the revocation finished.

Each row in the table represents an independent failure point. A revocation is complete only when every row has been checked, and the audit search returns no access events after the termination timestamp. Teams that repeat this checklist for every departing remote assistant build the same offboarding discipline that larger organizations enforce through IT service management tools.

What Should You Remember About Email Revocation After Offboarding?

Email revocation after offboarding is a verification process, not a one-time click. The executive's mailbox contains the highest concentration of business risk in any delegation arrangement, and a partial revocation can stay hidden until a client cites a leaked message or a privileged document surfaces somewhere it should not be. The most durable approach combines immediate session termination, explicit delegate removal, and a full forwarding-rule audit before the executive considers the matter closed.

The second thing to remember is that the access map should exist before the revocation becomes necessary. A written record of which mailbox permissions, connected apps, and rules a virtual assistant holds makes the offboarding sequence faster and more reliable. Executives who delegate email without that record tend to discover the missing information only during an incident, when time is short, and the former assistant is no longer available to answer questions. The discipline of documenting access during onboarding is therefore part of the same skill as revoking access during offboarding.