# 3.1 Identity and Access Management

# Goal

Identity and Access Management controls who can access company systems, what they can access, and what they are allowed to do.

This is one of the most important parts of the Protect section. Many attacks do not begin with malware. They begin with a login. A stolen password. A reused password. An old account. A weak admin account. A vendor account nobody reviewed. A fake MFA reset request. A shared password sitting in a spreadsheet.

The goal is simple:

Only the right people should have access to the right systems, for the right reason, at the right level, for the right amount of time.

# Step 1: Assign IAM Ownership

Assign clear ownership for identity and access management.

The company needs one person or role responsible for keeping this process alive. This may be the IT lead, MSP contact, operations manager, security lead, or another assigned owner.

Record the following:

Access decisions should not be left to informal messages or memory.

# Step 2: Define the Access Rules

Create simple rules for how access is granted, changed, and removed.

The rules should cover:

• No access without approval.

• No shared accounts unless formally approved.

• No elevated admin access for normal daily work not requiring that level of privileges for the task at hand.

• No permanent vendor access unless there is a clear business need.

• No former employee accounts left active.

• No MFA exceptions without written approval.

• No password storage in spreadsheets, browsers, chat messages, or email.

• No personal email accounts used for company systems.

• No user receives more access than needed for their role.

The company should write these rules in plain language and make them part of normal operations.

# Step 3: Centralize Identity Where Possible

Use one main identity system wherever possible.

For many SMEs, this will be Microsoft Entra ID through Microsoft 365 or Google Workspace identity through Google Workspace. For technical teams or self-hosted environments, this may include Keycloak, authentik, Authelia, FreeIPA, or another identity provider.

The goal is to reduce scattered logins. The more separate accounts the company has, the harder it becomes to control access.

Record which system is the main identity source:

Where single sign-on is available, use it for important systems.

# Step 4: Enforce MFA on Critical Systems

Multi-factor authentication must be enabled on critical systems.

Start with:

Use stronger MFA for administrators and high-risk users. Hardware security keys or passkeys are better than SMS codes.

Emergency exceptions must be documented, approved, time-limited, and reviewed.

# Step 5: Deploy a Password Manager

The company should use an approved password manager for all business passwords.

The password manager should be used to facilitate:

• Unique passwords
• Long random passwords
• Shared team credentials where unavoidable
• Secure password sharing
• Admin credentials
• Vendor portal credentials
• Recovery codes
• Emergency access records

Passwords should not be stored in spreadsheets, notebooks, browsers, chat apps, email, or personal password vaults.

The company should define:

# Step 6: Use Least Privilege

Every user should have the lowest level of access needed to do their job.

This applies to employees, executives, contractors, vendors, administrators, and service accounts.

For each important system, define standard access roles:

Do not give administrator access because it is convenient. Give it only when it is required.

# Step 7: Separate Admin Accounts from Daily User Accounts

Administrators should not use their normal everyday account for admin work.

Each administrator should have:

Admin accounts should have MFA, strong authentication, limited access, and higher monitoring. They should not be used for email, web browsing, or ordinary document work.

Break-glass accounts should be protected, documented, and reviewed regularly.

# Step 8: Remove or Restrict Shared Accounts

Shared accounts are dangerous because nobody can clearly prove who used the account.

The company should remove shared accounts wherever possible.

Where a shared account cannot be removed immediately, document:

Shared admin accounts should be treated as high risk.

# Step 9: Control Service Accounts and API Access

Service accounts are used by systems, scripts, integrations, automations, APIs, backup tools, monitoring tools, and SaaS connections.

These accounts are often forgotten which makes them dangerous.

For each service account, record:

Service accounts should not have broad admin rights unless absolutely required.

# Step 10: Protect Vendor and Contractor Access

Vendors and contractors should use named accounts. They should not use shared internal accounts.

Vendor access should be:

• Approved before use.
• Limited to the systems needed.
• Time-limited where possible.
• Protected with MFA.
• Removed when the work ends.
• Reviewed regularly.
• Logged where possible.

The company should record:

Do not allow permanent vendor access without a clear owner and review date.

# Step 11: Create a Joiner, Mover, Leaver Process

Access must change when people join, change roles, or leave.

Use a simple process:

Offboarding should include email, SaaS platforms, cloud storage, VPN, password manager, devices, admin tools, vendor portals, code repositories, and shared folders.

Do not only disable the main email account. That is not enough.

# Step 12: Review Access Regularly

Access reviews should happen on a fixed schedule.

For most SMEs, review critical systems quarterly and lower-risk systems at least annually.

Review:

• Email accounts
• Microsoft 365 or Google Workspace users
• Admin accounts
• Accounting and payroll users
• CRM users
• Cloud storage access
• Password manager users
• VPN and remote access users
• Website admin accounts
• Backup system users
• Security tool users
• Vendor accounts
• Former employees and contractors
• Shared accounts
• Service accounts

The review should answer:

• Who has access?
• Do they still need access?
• Is the access level correct?
• Is MFA enabled?
• Are any accounts inactive?
• Are there unknown users?
• Are there old vendor accounts?
• Are there shared accounts?
• Are there admin accounts that should be removed?

Record the review date, reviewer, findings, and actions taken.

# Step 13: Secure Account Recovery

Account recovery is often a weak point.

Attackers may not need a password if they can trick support staff into resetting MFA, changing a phone number, or sending a recovery link.

The company should define recovery rules:

• Verify identity before password resets.
• Verify identity before MFA resets.
• Use a known contact method, not the one provided during the request.
• Require manager approval for high-risk resets.
• Do not reset executive, finance, HR, IT, or admin accounts based only on email or chat.
• Record all emergency resets.
• Review all MFA resets for high-risk accounts.

Help desk and MSP staff must follow the same rules.

# Step 14: Protect High-Risk Roles

Some roles need stronger controls.

High-risk roles include:

• Executives
• Finance staff
• HR staff
• IT administrators
• MSP administrators
• Help desk staff
• Payroll users
• Accounting users
• Sales operations
• Customer data owners
• Developers
• Anyone with access to large data exports
• Anyone who can approve payments

For these users, apply stronger protections:

• MFA or passkeys.
• Hardware security keys where practical.
• Password manager required.
• No shared accounts.
• Reduced admin rights.
• Access reviewed more often.
• Extra verification for payment and account changes.
• Clear reporting path for suspicious requests.

# Step 15: Document Exceptions

Some systems may not support MFA, SSO, strong password rules, or proper role-based access.

Do not ignore those systems, record them.

For each exception, document:

Permanent exceptions are usually a sign of a bad system, weak vendor, or unfinished work.

# Step 16: Keep Evidence

The company should keep proof that IAM controls are working.

Useful evidence includes:

• MFA reports
• User lists
• Admin account lists
• Access review records
• Offboarding records
• Password manager user reports
• Vendor access records
• Service account register
• Screenshots of security settings
• SSO configuration records
• Conditional access settings
• Emergency access records
• Exception approvals

Keep this evidence in a controlled folder. It will help with audits, insurance, customer reviews, incident response, and management reporting.

# IAM Register Template

# Recommended Tools

# Practical Tool Stack for SMEs

# Very small company:

• Google Workspace or Microsoft 365 identity
• Built-in MFA
• Bitwarden or KeePassXC
• Google Sheets or Excel access review tracker

# Small company with Microsoft 365:

• Microsoft Entra ID
• Microsoft Entra MFA
• Bitwarden or Passbolt
• Windows LAPS
• Excel or SharePoint register

# Small company with Google Workspace:

• Google Admin Console
• Google 2-Step Verification
• Bitwarden or Psono
• Google Sheets register

# Self-hosted or technical company:

• Keycloak or authentik
• Authelia for protected internal apps
• FreeIPA for Linux/Unix access
• Bitwarden, Psono, or Passbolt
• OpenBao or Infisical for secrets

# Expected Outputs from This IAM Stage

At the end of this section, the company should have:

• An IAM owner
• Clear access rules
• A main identity provider or identity source
• MFA enabled on critical systems
• An approved password manager
• Separate admin accounts
• A list of shared accounts and removal plans
• A service account register
• A vendor access register
• A joiner, mover, leaver process
• A recurring access review process
• Documented account recovery rules
• Stronger controls for high-risk roles
• An exception register

Evidence showing that IAM controls are actually working.

# Objectives

• Do not make access control informal.

• Every account should have a purpose.

• Every admin should be named.

• Every vendor should have an owner.

• Every exception should expire.

• Every leaver should be removed quickly.

• Every critical system should use MFA.

• If the company cannot explain who has access and why, access is not under control.

---