Microsoft 365 and Google Workspace Account Lifecycle for Crew Changes

This article applies to yachts using Microsoft 365, Google Workspace, or similar cloud identity and productivity platforms for crew email, shared files, management communication, purchasing, calendars, guest operations, accounting, owner-office coordination, or technical documentation.

Applicability depends on who owns the tenant, whether the yacht is private or commercial, management-company policy, employment record practices, data-protection obligations, whether devices are yacht-owned or personal, and whether accounts connect to other systems such as PMS, procurement, shared drives, password vaults, Wi-Fi portals, AV/IT dashboards, or remote support tools.

The operational principle is simple: crew turnover is identity turnover. If account changes are handled casually, old access follows the person off the yacht.

Yacht account management often feels administrative until something goes wrong.

A departing crew member may still receive shared mailbox messages. A former engineer may still have access to a drive folder containing network diagrams. A shared iPad may still be signed into a previous user's account. A captain's old phone may still approve MFA prompts. A contractor may still belong to a Google Group or Microsoft Team long after the refit ended.

These are not exotic cyber scenarios. They are normal crew-change failures.

The goal is not to make onboarding slow. The goal is to make access intentional from the first day and removable on the last day.

Start with tenant ownership and responsibility.

Clarify:

• who owns the Microsoft 365 or Google Workspace tenant,
• who is the global or super admin,
• who approves new accounts,
• who disables departing accounts,
• who controls billing and licences,
• who can recover or transfer data,
• who manages MFA resets,
• who has emergency admin access.

On some yachts the tenant belongs to the management company. On others it belongs to the owner office, family office, vessel company, or a technical provider. That distinction matters during crew turnover. The captain should not discover during urgent offboarding that nobody knows who can disable an account.

Create accounts from role and access need, not convenience.

Before creating an account, confirm:

• crew member's legal or working name,
• role onboard,
• department,
• start date,
• expected end date if temporary,
• line manager or approver,
• mailbox requirement,
• shared mailbox requirement,
• group or drive access,
• device type,
• MFA method,
• recovery contact process.

Use named individual accounts for crew. Avoid shared human accounts such as `engineer@yacht...` or `deckhand@yacht...` for daily work. Shared role addresses can exist as shared mailboxes or groups, but the person using them should still authenticate as themselves.

This gives the yacht a cleaner audit trail and makes offboarding possible.

MFA should be enabled for crew and especially for administrators, captains, pursers, owner-office users, and anyone with access to files, finance, procurement, management platforms, or technical records.

The important detail is not only whether MFA exists. It is whether MFA can survive crew movement.

Check:

• MFA method registered,
• backup method available,
• recovery process documented,
• admin emergency account controlled,
• departing crew member removed from authentication methods,
• old phone numbers removed,
• authenticator apps reset when devices change,
• conditional access or security defaults reviewed where used.

Do not let a departing phone remain an approval device for an active account. That is one of the most common ways access control quietly fails.

Yachts often use role-based addresses: captain, chief engineer, purser, accounts, itinerary, charter, crew, or technical support.

Those should usually be shared mailboxes, aliases, groups, or delegated mailboxes, not personal accounts passed from one crew member to another.

When someone joins:

• give their personal account access to the role mailbox,
• record the mailbox owner,
• confirm send-as or send-on-behalf permissions,
• confirm mobile access where needed,
• confirm retention and handover expectations.

When someone leaves:

• remove delegated access,
• remove send permissions,
• review mailbox forwarding,
• check rules and auto-forwarding,
• preserve needed handover data,
• update shared mailbox membership.

Mail forwarding deserves special attention. A hidden forwarding rule can leak yacht email long after the account itself appears disabled.

Groups are where access often spreads.

Review:

• Microsoft Teams,
• Microsoft 365 Groups,
• SharePoint sites,
• OneDrive sharing links,
• Google Groups,
• Google Shared Drives,
• Drive folders,
• calendar permissions,
• external guest accounts,
• vendor collaboration spaces.

For each crew role, keep a standard access profile. A temporary deckhand, chief engineer, purser, captain, AV/IT contractor, and management-company user should not all receive the same group bundle.

Avoid old project groups becoming permanent access paths. A refit group, shipyard group, or guest-trip folder should have an owner and closure date.

Account lifecycle is not complete until devices are handled.

Check:

• yacht-owned laptops,
• phones,
• tablets,
• shared bridge or crew devices,
• owner-office devices,
• onboard admin workstations,
• mobile email profiles,
• browser sessions,
• cached cloud files,
• password managers,
• authenticator apps.

For yacht-owned devices, wipe or reset according to platform policy before reassignment. For personal devices, remove the work profile, revoke sessions, and confirm company or yacht data is no longer synchronising.

Do not rely on verbal confirmation. The admin console should show the account signed out, sessions revoked, or device action completed where possible.

Offboarding should be timed. Immediate lockout may be appropriate for termination or risk, but normal handover may require a planned sequence.

A standard offboarding sequence:

1. Confirm departure date and access cutoff time.
2. Identify accounts, aliases, groups, drives, devices, and admin roles.
3. Preserve required handover data.
4. Transfer ownership of files, calendars, and shared records.
5. Remove admin roles.
6. Remove group and mailbox access.
7. Revoke sessions.
8. Disable sign-in.
9. Wipe or reset yacht-owned devices.
10. Remove MFA methods linked to departing devices.
11. Convert or archive mailbox where required.
12. Record completion evidence.

For high-risk departures, remove access first and handle data preservation through an administrator.

Do not delete first and ask questions later.

Before removal, decide what must be preserved:

• operational handover notes,
• maintenance records,
• purchase records,
• technical documents,
• vendor correspondence,
• charter or guest records,
• safety or compliance evidence,
• incident notes,
• contracts and invoices,
• shared calendars,
• owner-office communication where applicable.

The preservation decision should come from captain, management, or authorised shore support, not from the departing user alone.

A second engineer leaves after a busy yard period. Their Google account has access to shared engineering folders, generator service reports, switchboard photos, warranty emails, and a temporary refit group. Their phone is also registered for MFA.

If the account is simply deleted, the yacht may lose useful handover data. If the account is left active, the former crew member may still access sensitive records.

The correct path is controlled offboarding: transfer ownership or copy required files into the yacht's engineering records, remove group access, revoke sessions, remove the MFA device, disable the account, and document what was preserved.

This protects both sides. The yacht keeps its evidence, and the former crew member is not left holding access they should no longer have.

Do not share one login between rotating crew. It may feel simple, but it destroys accountability and makes offboarding nearly impossible.

Do not forget shared mailboxes and groups. Disabling the personal mailbox is not enough if the person still has group or delegated access.

Do not leave old MFA devices attached. Authentication methods are part of access control.

Do not delete accounts before checking file ownership and operational records.

Do not let vendors or temporary contractors remain in collaboration spaces after the job ends.