Employee Onboarding and Offboarding

Employee Onboarding and Offboarding

Photo by RDNE Stock project on Pexels

Onboarding and offboarding are the two highest-risk moments in access management. During onboarding, there's pressure to get the new hire productive quickly, often leading to over-provisioning access. During offboarding, there's often urgency to remove access quickly, but cleanup is frequently incomplete—forgotten accounts remain active and become security liabilities. A documented, repeatable process for both is essential.

Onboarding: Granting the Right Access

A structured onboarding process ensures new employees get exactly the access they need—no more, no less—and that every access decision is documented. Here's a step-by-step checklist:

1. Create account in identity provider (Microsoft 365 or Google Workspace). Assign the appropriate role group (see Section 4, Lesson 1 on RBAC).
2. Provision application access based on role: CRM for sales, accounting software for finance, etc. Use role-based assignments, not individual grants.
3. Set up MFA on day one. Have the new employee install the authenticator app and complete MFA enrollment during their first IT orientation session.
4. Issue hardware with standard user rights (NOT local admin). Install endpoint protection before handing over the device.
5. Enroll in password manager and help the employee set up their master password. Add them to appropriate shared vaults.
6. Document the access in an access log: employee name, role, systems accessed, date granted, approver. This log is critical for offboarding and audits.
7. Schedule a 30-day review to verify the employee's access matches their actual responsibilities and adjust if needed.

Offboarding: Removing All Access

Offboarding must be thorough and immediate. A former employee with active credentials is one of the most common sources of data breaches. Follow this checklist:

1. Disable the identity provider account immediately (not delete—disable first, delete after 30 days in case you need to recover emails or files).
2. Revoke all application access. Go through the access log created during onboarding and revoke each system. Don't forget: CRM, accounting, social media, vendor portals, cloud storage, VPN.
3. Recover hardware before the employee's last day if possible. Change the device password and wipe if policy requires.
4. Change shared passwords that the employee knew. If you're using a password manager with shared vaults, simply remove the employee from the vault—shared passwords don't need to change.
5. Forward email to a manager or replacement. Set an auto-reply with the new contact information.
6. Review for shadow IT. Check if the employee signed up for any services using their company email that IT doesn't know about. Check the access log and ask the employee's manager.
7. Document the offboarding in the access log: employee name, date offboarded, systems revoked, who performed the offboarding.
8. Wait 30 days, then delete the account after confirming no forwarded emails or files are needed.

The Access Log: Your Single Source of Truth

Maintain a spreadsheet or document listing every employee and their access to each system. Update it during onboarding, role changes, and offboarding. This log serves three purposes:

• Security: You know exactly what to revoke when someone leaves
• Compliance: Auditors will ask for this documentation
• Efficiency: When someone changes roles, you can see what needs to be added and removed

A simple Google Sheet or Excel file is sufficient for most small businesses. Columns: Employee Name, Role, System, Access Level, Date Granted, Date Revoked, Notes.

Key Takeaways

• Onboarding: Use role-based access, set up MFA on day one, document everything in an access log
• Offboarding: Disable immediately, revoke all access, recover hardware, change shared passwords
• Maintain an access log as your single source of truth for who has access to what
• Schedule a 30-day post-hire review to verify access matches actual responsibilities
• Delete accounts after 30 days, not immediately, to allow recovery of emails and files

Single Sign-On and Identity Federation

Single Sign-On (SSO) allows users to authenticate once and access multiple applications without re-entering credentials. SSO improves security (fewer passwords means fewer targets for attack), user productivity (less time spent on authentication), and IT efficiency (centralized access management and immediate revocation). For organizations using cloud applications like Google Workspace or Microsoft 365, SSO is already available — users log in once to their email and automatically access all integrated applications.

Implementing SSO requires an identity provider (IdP) — a central service that manages user identities and authentication. Free and open-source IdP options include: Keycloak (full-featured, supports SAML and OIDC, integrates with Active Directory), Authentik (modern, flexible, great for homelabs and small businesses), and LemonLDAP::NG ( lightweight, good for web applications). Cloud-based IdPs like Google Workspace Identity, Microsoft Entra ID (formerly Azure AD), and Okta provide SSO as a managed service with free tiers for small numbers of users. Most modern applications support SSO through SAML or OpenID Connect (OIDC) standards.

Identity federation extends SSO beyond your organization — it allows users from partner organizations to access your applications using their own credentials, and vice versa. This is common in B2B scenarios: a supplier accesses your procurement portal using their own corporate login, without you needing to create and manage an account for them. Federation requires trust relationships between identity providers and careful configuration of attribute mappings (what user information is shared). For most small to mid-sized businesses, federation is an advanced feature — focus on internal SSO first, and extend to federation when business partnerships demand it.

Common Questions

Q: What happens if the SSO provider goes down?

This is the SSO 'single point of failure' risk. If your IdP is unavailable, users can't access any SSO-integrated applications. Mitigation strategies include: choosing a highly available IdP (cloud providers offer 99.9%+ SLAs), keeping emergency local admin accounts that don't depend on SSO, implementing break-glass procedures for critical access during outages, and monitoring IdP availability with automated alerts. Document the recovery procedure and test it annually.