FC-03 · User Access Control — IT Staff Technical Procedures

This content is visible to isms-it-staff and isms-security via Scroll Content Manager. The all-staff behavioural guidance appears above this section for all users. What follows is the operational implementation detail for IT Operations staff.

Technical implementation overview

User access control is implemented across four integrated platforms that must be kept in sync. Understanding how they interact prevents provisioning gaps and audit failures.

Microsoft Entra ID (Azure AD) is the authoritative identity store. Every human user, service account, and device has an object in Entra ID. All authentication for cloud services and modern-auth capable on-premises systems federates through Entra ID. Conditional Access policies in Entra ID enforce MFA and device compliance requirements.

Active Directory (on-premises) remains the authority for legacy systems, GPO application, and Kerberos authentication on the internal network. Entra ID Connect synchronises from AD to Entra ID — the canonical source of truth for user object attributes is on-premises AD. Changes made directly in Entra ID for synchronised objects are overwritten at the next sync cycle (every 30 minutes by default).

PAM platform (CyberArk / BeyondTrust / Delinea — insert deployed product) manages all privileged credential checkout, session recording, and just-in-time access for admin accounts. No privileged account password is known to any human user — all privileged access is PAM-mediated.

MDM platform (Microsoft Intune / Jamf) manages device enrolment, compliance policy, and the device object that Conditional Access evaluates. A user account without a compliant enrolled device cannot access CUI-scope resources regardless of valid credentials and MFA.

Joiner provisioning workflow

Trigger and initiation

Provisioning is triggered by an approved onboarding request from HR. The request must exist in the ITSM platform before any account is created. Do not provision accounts on the basis of verbal requests, emails, or messages from line managers — the formal ITSM request is the authorisation record that satisfies AT-PS 3.9.1 (screening complete before access) and AT-IA 3.5.1 (individual account creation).

Provisioning gate — mandatory check before creating any account:

The onboarding request must include HR confirmation that pre-employment screening is complete and the result is satisfactory. The screening confirmation field in the ITSM form must be populated by HR, not by the line manager or by IT Operations. If the screening confirmation is absent or shows screening is still in progress, do not provision the account. Contact HR to confirm status and annotate the ITSM ticket with the reason for the hold.

This gate is the control that satisfies NIST 800-171 3.9.1. An assessor will cross-reference provisioning dates in AD (EV-D03) against screening completion dates in EV-B08. The provisioning date must not precede the screening completion date.

Step-by-step provisioning procedure

Step 1 — Create the AD user object

Location: Active Directory Users and Computers → [OU path for new users]
OU structure:
  OU=Users
    OU=Standard (all standard staff)
    OU=Contractors (time-limited accounts)
    OU=Service Accounts (never use for human users)

Required attributes:
  Display Name: [First] [Last]
  User Principal Name: firstname.lastname@[domain] 
    (disambiguate with suffix if name collision: firstname.lastname2@)
  SAMAccountName: f.lastname (15-char limit)
  Email: firstname.lastname@[domain] (match UPN)
  Department: [from ITSM request]
  Job Title: [from ITSM request]
  Manager: [from ITSM request — required for access reviews]
  Employee ID: [from ITSM request — links to HR system]
  Account Expiry:
    Permanent staff: no expiry date
    Contractors: set to contract end date + 1 day
    (Never leave contractor accounts with no expiry)

Password settings:
  Generate a random password using [approved password generator / PAM]
  Tick: "User must change password at next logon"
  Do NOT tick: "Password never expires" — FGPP handles this

Account state: Enabled

Step 2 — Apply the correct Fine-Grained Password Policy (FGPP)

FGPP is applied via AD security group membership, not directly to the account.

Standard accounts: add to group FGPP-Standard-Users
  → 16-char minimum, 24-password history, 5 lockout attempts, 15-min lockout

Privileged accounts: add to group FGPP-Privileged-Users  
  → 20-char minimum, 24-password history, 5 lockout attempts, 30-min lockout
  (Privileged accounts are created separately — see Privileged Account Management section)

Step 3 — Wait for Entra ID Connect sync

Sync cycle is every 30 minutes by default. Force a delta sync if provisioning is time-sensitive:

# On the Entra ID Connect server
Start-ADSyncSyncCycle -PolicyType Delta

Verify the account appears in Entra ID admin centre before proceeding. The account must be visible in Entra ID before licences, MFA, and Conditional Access can be applied.

Step 4 — Assign Microsoft 365 licence

Entra ID admin centre → Users → [new user] → Licences → Add assignments
Assign: Microsoft 365 Business Premium (or equivalent — includes Defender, Intune, Entra P1)
Usage location: United Kingdom (required for licence assignment)

Step 5 — Enrol device in MDM

The user's device must be enrolled before they can access CUI-scope resources. Enrolment method depends on device type:

Windows (Entra ID joined — preferred for new devices):
  Out-of-box experience → Sign in with work account → Device auto-enrolls
  Verify: Intune admin centre → Devices → [device name] → shows Compliance: Compliant

Windows (hybrid joined — existing domain-joined devices):
  Autopilot profile OR manual enrolment via Company Portal app

macOS:
  Jamf enrolment via Company Portal or Jamf Self Service
  Manual: System Preferences → Privacy & Security → [MDM profile install]

Verify enrolment: Intune → Devices → device shows:
  Managed by: Intune
  Compliance state: Compliant
  Last check-in: within 24 hours

Step 6 — Configure MFA

MFA must be registered before the user's first login to any CUI-scope resource. The MFA registration process is triggered by Conditional Access — on first login after MFA is required by CA policy, the user is prompted to register. However, for new users it is better to guide them through registration during onboarding rather than leaving them to encounter the registration flow unguided.

Full MFA configuration procedure is in the [MFA Configuration section below].

Step 7 — Provision role-based access

Access is provisioned via AD group membership. Do not grant permissions directly to the user object — only via groups. This ensures access is auditable, revocable in bulk, and consistent across the review process.

Standard access (all users):
  Add to: GRP-AllStaff-M365 (Microsoft 365 base access)
  Add to: GRP-AllStaff-CorporateWiFi
  Add to: GRP-AllStaff-FilePrinting (general file server)

Role-specific access (from ITSM request):
  Engineering: add to GRP-Engineering-FileShare, GRP-Engineering-Projects
  Finance: add to GRP-Finance-FileShare (DO NOT add to Engineering groups)
  etc.

CUI access (requires separate CISO approval — not standard provisioning):
  GRP-CUI-Access → requires CISO approval field in ITSM request
  Do not add to this group on the basis of line manager request alone

Step 8 — Physical access card provisioning

Notify Facilities via the ITSM ticket to issue a physical access card. IT Operations does not directly manage the ACS — Facilities owns the ACS system. However, IT Operations must confirm to Facilities:

The employee's name and employment start date
Zone access required (Zone 1+2 for standard staff; Zone 3 requires IT Manager approval)
Contractor flag and access expiry date if applicable

Do not issue Zone 3 server room access to any new joiner as a default, regardless of their IT role. Zone 3 access is individually authorised by the IT Manager on the basis of demonstrated need.

Step 9 — Generate and communicate temporary credentials

Temporary password requirements:
  - System-generated random password (use PAM password generator or 
    approved tool — never use a predictable pattern)
  - Minimum 20 characters for temporary passwords
  - "User must change at next logon" must be set
  - Expires after 24 hours if not used — enforce via account expiry 
    attribute set to start date + 1 day, updated on first login

Communication:
  - Username: communicate to user via line manager
  - Temporary password: communicate DIRECTLY to user via personal 
    mobile phone (SMS or call) — NEVER via company email or via the 
    line manager's email
  - MFA registration link: include in the password communication

Step 10 — Log the provisioning event (EV-D03)

Every provisioning event must be logged in the JML register (EV-D03). The log entry must be created at the time of provisioning, not retrospectively. Required fields:

EV-D03 JML Log entry — Joiner:
  Date and time of account creation (UTC)
  Employee/contractor name
  UPN created
  ITSM request reference number
  Screening confirmed: Yes — HR confirmation reference [date]
  Account type: Standard / Contractor / [other]
  Zone access granted: Zone 1+2 / Zone 3 (with approval reference)
  CUI access granted: Yes (CISO approval ref) / No
  MFA enrolled: Yes / Pending (flag for follow-up)
  Provisioned by: [IT Operations engineer name]
  Line manager: [name] — approves role-based access
  Notes: any deviations from standard process with justification

The JML log is filed in EV-D · Access Control → JML Log. A gap in the JML log for any period is a finding during access review.

Mover procedure — role changes and transfers

A mover event occurs when an employee changes role, transfers department, or takes on additional responsibilities that change their access requirements. The mover procedure runs through the same gate check as the joiner procedure: the change must be initiated via an ITSM request from HR or the new line manager.

Access change principle — always additive minus excess:

The mover process must both add access needed for the new role AND remove access no longer needed from the old role. Access is not cumulative across role changes. An employee who moves from Engineering to Finance should not retain Engineering file share access unless there is a specific documented reason. Review both sides of every mover event.

Mover procedure steps:

1. Receive approved ITSM mover request (HR or new line manager)
2. Identify new role access groups required
3. Identify old role access groups to be removed
4. Update AD group membership:
   - Add new role groups
   - Remove old role groups that are no longer appropriate
5. Update AD object attributes:
   - Department field
   - Manager field (critical for access review)
   - Job Title
6. If moving to CUI-scope role: require CISO approval for CUI group
7. If Zone 3 access newly required: require IT Manager approval
8. If Zone 3 access no longer required: notify Facilities to update ACS
9. Log the mover event in EV-D03:
   Date, UPN, ITSM reference, access removed, access added, approved by

For role changes that significantly increase CUI access (moving from non-CUI to CUI scope, or expanding CUI access categories), verify with HR that screening level is still appropriate for the new access level. Reference the screening matrix in AT-PS Section 3. If a higher screening level is required, the new CUI access must not be granted until the upgraded screening is complete.

Leaver de-provisioning workflow

De-provisioning is the most security-critical JML event. Delays in access revocation are one of the most consistently found issues in access control audits. The standard is same-day revocation — access is revoked on the final working day, or immediately for involuntary terminations.

Trigger and advance notice

For voluntary leavers, IT Operations should receive notification from HR at least five working days before the final day. This advance notice period allows IT Operations to prepare the de-provisioning steps, review the SIEM for the preceding 30 days (see Step 3 below), and notify Facilities to prepare card revocation.

For involuntary terminations, IT Operations must be briefed before the termination conversation and must be ready to execute Steps 1 through 5 immediately on confirmation that the individual has left the building.

De-provisioning steps

Step 1 — Pre-departure SIEM review (must occur BEFORE account disable)

Before disabling the account, the security analyst or IT Manager reviews the SIEM for the departing user's account activity over the preceding 30 days. Specifically looking for:

Review queries to run (or request from security analyst):
  - Unusually large file downloads (volume anomaly — what is their 
    typical daily download volume?)
  - Access to file shares or systems outside their normal pattern
  - Data transfers to external locations (email attachments to personal 
    accounts, uploads to cloud storage)
  - After-hours access events
  - Access to CUI-scope resources they do not normally access

Review output:
  - Clean: note "SIEM 30-day review completed — no anomalies" in EV-D04
  - Anomaly found: immediately notify CISO before disabling account — 
    do not disable until CISO has assessed; may need to trigger AT-IR 
    incident response

This step must happen before the account is disabled because reviewing activity on a disabled account is technically possible but operationally harder, and because an active download in progress should be intercepted before it completes.

Step 2 — Disable the Entra ID / AD account

On-premises AD (sync'd to Entra ID):
  Active Directory Users and Computers → right-click account → Disable Account

Entra ID (for cloud-only accounts or emergency):
  Entra ID admin centre → Users → [user] → Edit → Block sign-in: Yes

Verify the disable propagated to Entra ID:
  Entra ID → Users → [user] → Account enabled: No
  (May take up to 30 minutes for sync; force delta sync if urgent)

Revoke all active sessions immediately:
  Entra ID → Users → [user] → Revoke sessions
  This invalidates all current refresh tokens — the user's active 
  sessions on all devices are terminated within 60–90 seconds

Step 3 — Revoke MFA methods

Entra ID → Users → [user] → Authentication methods
  Delete all registered methods:
    - Microsoft Authenticator app registrations
    - FIDO2/hardware keys
    - Phone numbers
    - Software OATH tokens

This prevents a retained phone from being used to approve MFA requests
after departure, which would be possible if only the account was disabled.

Step 4 — Remove from all AD groups

# Get all groups the user is a member of
Get-ADPrincipalGroupMembership -Identity "username" | Select Name

# Remove from all non-default groups
# (Do not remove from Domain Users — this is a default and its removal 
# causes issues)
Get-ADPrincipalGroupMembership -Identity "username" | 
  Where-Object {$_.Name -ne "Domain Users"} | 
  ForEach-Object {Remove-ADGroupMember -Identity $_ -Members "username" -Confirm:$false}

Step 5 — Revoke physical access (notify Facilities)

Notify Facilities immediately with:

Employee name and employee ID
Requested deactivation time (immediately for involuntary terminations; end of final working day for voluntary leavers)
Card return status (whether the card was physically returned or is still outstanding)

Facilities deactivates the card in the ACS within the required window. IT Operations receives confirmation from Facilities and logs the deactivation timestamp in EV-D04.

Step 6 — Retrieve and process equipment

Equipment to retrieve on or before final day:
  Company laptop — confirm with IT Operations for re-imaging or disposal
  Hardware security keys (YubiKey or equivalent)
  Mobile phone (if company-issued)
  Access card (confirmed via Facilities)
  Printed CUI documents — confirm with HR via exit checklist

If equipment not returned on final day:
  Initiate MDM remote wipe within 24 hours of non-return
  Log the remote wipe initiation timestamp in EV-D04
  Note: remote wipe confirmation may take minutes to hours depending 
  on device connectivity status

Step 7 — Data custody transfer

OneDrive / personal file storage:
  Entra ID → Users → [user] → OneDrive → Access user's OneDrive as admin
  Transfer ownership of work files to line manager's account
  Retain data for 90 days per the account hold policy (AT-IA 3.5.9)

Shared mailbox (if applicable):
  Do not auto-forward to personal email — this is explicitly prohibited
  Convert to shared mailbox if team access needed, or set manager as 
  delegate with full access

Remove from external systems:
  Cloud services with individual accounts (document each in EV-D04)
  Supplier portals where individual was a named user
  Partner system accounts
  This step is frequently missed — review the asset register and any 
  system access noted in the account's service desk history

Step 8 — Account hold and scheduled deletion

Do not delete the account immediately. Per AT-IA 3.5.9:
  Set account description to: "DISABLED - Leaver [DATE] - Delete [DATE+90]"
  Account remains disabled for 90 days to preserve audit trail linkage

Schedule deletion:
  Add to IT Operations calendar: delete account on [DATE+90]

On deletion date:
  Verify no open investigations reference the account
  Permanently delete the account object
  Log deletion in EV-D04: deletion date, confirmed by [engineer name]

Step 9 — Complete and file EV-D04

The leaver de-provisioning checklist (EV-D04) must be completed and filed within 5 working days of the final day. Required signature fields:

IT Operations sign-off confirms:
  Account disabled timestamp (UTC)
  Sessions revoked timestamp (UTC)
  MFA methods removed: Y/N
  Physical access card deactivated timestamp (from Facilities confirmation)
  Equipment retrieved or remote wipe initiated
  Data transferred to line manager
  External system access removed
  90-day hold set — deletion scheduled for [date]

HR sign-off confirms:
  Exit interview conducted
  Ongoing obligations communicated
  NDA departure acknowledgement signed (EV-B09 reference)
  Company property returned

CISO sign-off confirms:
  SIEM 30-day review completed — result: Clean / Anomaly investigated
  If anomaly: incident record reference
  DEFSTAN contracting authority notified if SC/DV clearance held: Y/N/NA

Privileged account management

The dual-account model

Every member of IT Operations and every person with administrative privileges operates a dual-account model. No exceptions.

Standard account (firstname.lastname@domain.com):
  Used for: email, Teams, browsing, general office productivity
  Access to: all resources their role requires, excluding admin systems
  MFA: required (authenticator app or FIDO2)

Privileged account (adm-firstname.lastname@domain.com):
  Used for: administrative tasks ONLY — never for email or browsing
  Access to: administrative systems via PAM only
  MFA: FIDO2 hardware key required (TOTP not acceptable for admin accounts)
  PAM-mediated: all privileged actions go through PAM checkout

The naming convention adm-firstname.lastname makes privileged accounts visually distinct in audit logs. If an adm- account appears in a SIEM event in a context that should not involve administrative access, it is immediately anomalous.

Creating a privileged account

1. Receive IT Manager approval for the privileged account creation
   (documented in ITSM ticket — not verbal)

2. Create the AD object:
   OU: OU=Privileged,OU=Admin Accounts
   UPN: adm-firstname.lastname@[domain]
   Display Name: ADM - [First Last]
   Password: generated by PAM — never known to any human
   "User cannot change password": ticked
   "Password never expires": ticked (PAM rotates automatically)

3. Add to FGPP-Privileged-Users group (20-char minimum, 30-min lockout)

4. Add to appropriate admin groups:
   Domain Admins — only if absolutely required
   Server Operators / Backup Operators — per role
   Entra ID role assignments: Global Admin only with CISO approval

5. Register in PAM platform:
   Create account object in PAM vault
   Assign to appropriate safe (safe = logical grouping by system scope)
   Set password rotation: every 24 hours (or on checkout completion)
   Assign access to: named users only (not group-based for PAM vaults)

6. Enrol FIDO2 hardware key:
   Issue YubiKey or equivalent from hardware inventory
   Register in Entra ID Authentication Methods for the privileged account
   Test successful authentication
   Record hardware key serial number in EV-D19 (privileged account register)

7. Log in EV-D03 (privileged account provisioning):
   Privileged UPN, ITSM reference, IT Manager approval reference, 
   FIDO2 key serial, PAM safe assigned, provisioned by, date

PAM session workflow for engineers

Every administrative action on a CUI-scope system must be PAM-mediated. The sequence:

1. Engineer logs into PAM platform using privileged account + FIDO2 key
2. PAM verifies credentials, checks authorised access list for the requested safe
3. Engineer requests checkout of specific credential (e.g. "Server-PRODDB01-LocalAdmin")
4. PAM grants checkout with time limit (default: 4 hours; set to minimum required)
5. PAM injects the credential into the session — engineer never sees the password
6. Session recording begins automatically on PAM (all keystrokes and screen captured)
7. Engineer performs the required administrative task
8. Engineer ends session — PAM terminates checkout and rotates the credential
9. Session recording filed in PAM platform — accessible to CISO for EV-F07 review

For remote vendor access, the same PAM flow applies — the vendor authenticates to the PAM platform (via a vendor-specific account), not directly to the target system. See AT-MA for the remote maintenance MFA configuration detail.

Break-glass (emergency) account procedure

Break-glass accounts are for genuine emergencies where normal PAM access 
is unavailable (PAM platform outage, lockout scenario):

Two break-glass accounts exist:
  BG-Admin-01: Domain Administrator scope
  BG-Admin-02: Entra ID Global Administrator scope

Storage:
  Credentials stored in sealed physical envelope in the CISO's fire safe
  Envelope is signed across the seal — any access is visible
  Envelope opened only with CISO + IT Manager joint authorisation

FIDO2 requirement:
  Break-glass accounts have a dedicated FIDO2 hardware key stored with 
  the sealed credential envelope

After any use:
  Immediately rotate all break-glass credentials
  Log the use in SIEM as a Critical alert (SIEM rule: BG account logon)
  Report to CISO within 1 hour of use
  Review is mandatory at next CAB meeting

Annual verification:
  CISO and IT Manager verify envelope integrity (seal unbroken)
  Credentials tested for validity in an isolated environment
  FIDO2 key tested for functionality
  Verification logged in EV-D19

MFA configuration

Entra ID Conditional Access — the four required policies

MFA for all CUI-scope accounts is enforced via Conditional Access (CA) policies, not per-user MFA settings. CA policies are evaluated at every authentication — they are the technical implementation of AT-IA 3.5.3.

Per-user MFA settings (the legacy "Manage MFA" panel in Entra ID) must be disabled or set to "disabled" for all users — CA policies and legacy per-user MFA conflict and create unpredictable behaviour.

Policy 1 — Privileged account MFA all access (highest priority)

Name: CA-001-AdminMFA-AllAccess
Assignments:
  Users: All administrator directory roles 
         (select all: Global Admin, Security Admin, User Admin, 
          Exchange Admin, SharePoint Admin, etc.)
  Cloud apps: All cloud apps
  Conditions: None (no exclusions — MFA applies even from trusted networks)
Grant:
  Require: Multifactor authentication
  Require: Compliant device
  (Both required — AND condition)
Session:
  Sign-in frequency: Every time
  Persistent browser session: Never

Priority: 1 (evaluated first)
Enable policy: On

Policy 2 — Non-privileged account MFA for network access

Name: CA-002-UserMFA-NetworkAccess
Assignments:
  Users: All users
  Exclude: Break-glass accounts (BG-Admin-01, BG-Admin-02)
           Emergency service accounts (document exclusions individually)
  Cloud apps: All cloud apps
  Conditions:
    Platforms: Any device
    Locations: All locations (do NOT exclude any named locations)
Grant:
  Require: Multifactor authentication
  Require: Compliant device OR Hybrid Entra ID joined device
Session:
  Sign-in frequency: 1 hour for CUI-scope apps (configure per-app 
                     for higher sensitivity applications)
  Persistent browser: Allowed for low-sensitivity apps

Priority: 2
Enable policy: On

Policy 3 — Legacy authentication block

Name: CA-003-BlockLegacyAuth
Assignments:
  Users: All users
  Cloud apps: All cloud apps
  Conditions:
    Client apps: Exchange ActiveSync clients + Other clients
                 (these are the legacy protocol identifiers)
Grant:
  Block access

Priority: 3
Enable policy: On

Verification:
  Entra ID → Sign-in logs → filter by Client app = "Other clients"
  Goal: zero successful authentications via legacy protocols
  Any successful legacy auth event = CA policy misconfiguration

Policy 4 — Break-glass exclusion policy

Name: CA-004-BreakGlass-Exclusion
Assignments:
  Users: BG-Admin-01, BG-Admin-02 (individual user objects, not groups)
  Cloud apps: All cloud apps
Grant:
  Require: Multifactor authentication (FIDO2 only — via authentication 
           strength policy set to Phishing-resistant MFA)
Session:
  Sign-in frequency: Every time

This policy does NOT exclude break-glass accounts from MFA — it applies 
STRONGER MFA (FIDO2 only) and removes the compliant device requirement, 
since break-glass scenarios may involve emergency devices.

Priority: 4 (must be evaluated after policy 2 to ensure MFA still applies)
Enable policy: On

MFA method configuration

Entra ID → Security → Authentication methods → Policies

Microsoft Authenticator:
  Enable: Yes
  Target: All users
  Authentication mode: Push (number matching)
  Additional settings:
    Number matching: Enabled (mandatory — prevents MFA fatigue attacks)
    Additional context: Enabled (shows app name and location in notification)

FIDO2 security keys:
  Enable: Yes
  Target: All users (required for privileged accounts)
  Key restrictions: Not restricted (or restrict to approved FIDO2 
                    manufacturer AAGUIDs if higher assurance needed)

Temporary Access Pass:
  Enable: Yes
  Target: All users
  Use: One-time for new device enrolment or MFA recovery
  Maximum lifetime: 4 hours
  One-time use: Yes (regenerate per-use, not reusable)

SMS (one-time passcode):
  Enable: No (explicitly disabled)
  Rationale: SIM-swap vulnerable; not acceptable for CUI-scope accounts

Voice calls:
  Enable: No (explicitly disabled)

Software OATH tokens (third-party TOTP):
  Enable: Yes — for standard user accounts where Authenticator is not feasible
  Do not enable for privileged accounts — FIDO2 required

MFA registration process for new users

IT Operations guides new users through MFA registration during onboarding:

1. Have the user log in to their new account from their enrolled device
2. CA Policy 2 will intercept the login and present the MFA registration flow
3. Guide the user through registering Microsoft Authenticator:
   a. User downloads Microsoft Authenticator on personal phone
   b. Entra ID presents QR code → user scans in Authenticator app
   c. Authenticator shows 6-digit code → user enters to verify
   d. Number matching push notification test → user approves
   e. Registration complete
4. For privileged accounts: additionally register FIDO2 hardware key:
   Entra ID → [user] → Authentication methods → Add method → Security key
   User connects YubiKey via USB → follows browser prompts → sets PIN
5. Record MFA registration in EV-D03 joiner log:
   "MFA enrolled: Yes — Authenticator app [date] / FIDO2 key [serial] [date]"

MFA coverage verification (generates EV-D05)

The quarterly MFA coverage report is the primary evidence for AT-IA 3.5.3. Run this report and file it as EV-D05 each quarter.

Check 1 — Entra ID MFA registration coverage:
  Entra ID → Identity → Monitoring & health → Authentication methods → 
  Registration and reset → MFA-capable report
  Export: all users showing MFA registration status
  Acceptable result: 100% of in-scope users registered for MFA
  Action on non-100%: identify non-registered users, initiate registration

Check 2 — CA policy coverage (no MFA bypass):
  Entra ID → Monitoring → Sign-in logs
  Filter: Status = Success AND Conditional access = Not applied
  Acceptable result: Zero successful logins where CA did not apply
  (Any CA-not-applied success = policy gap)

Check 3 — Legacy auth usage:
  Entra ID → Sign-in logs
  Filter: Client app = Other clients OR Exchange ActiveSync clients
  Filter: Status = Success
  Acceptable result: Zero successful legacy auth logins

Check 4 — AWS IAM users without MFA (if applicable):
  AWS Console → IAM → Credential report (download CSV)
  Filter: mfa_active = FALSE
  Acceptable result: Zero IAM users without MFA

Check 5 — Privileged account MFA method verification:
  Entra ID → Users → Filter: Assigned roles is not empty
  For each: Authentication methods tab → confirm FIDO2 registered
  Acceptable result: All privileged accounts have FIDO2 registered

Check 6 — Break-glass account audit:
  Entra ID → Sign-in logs → Filter: User = BG-Admin-01 OR BG-Admin-02
  Acceptable result: Zero sign-in events in the review period
  Any sign-in event = initiate review per break-glass procedure

File output:
  Export each check as CSV or screenshot
  Compile into EV-D05 quarterly MFA coverage report
  File in: EV-D · Access Control → MFA Status Report → [YYYY-QQ]
  CISO review and sign-off required before filing

Quarterly privileged account review (generates EV-D01)

The quarterly privileged account review verifies that every account with elevated access still requires that access, is held by an active employee or contractor, and is correctly configured. It is a mandatory evidence item for AT-AC 3.1.5 and AT-AC 3.1.6.

Who conducts the review

The IT Manager conducts the review. The CISO reviews and signs off the output. Ideally a second IT Operations engineer cross-checks the active status of accounts against the HR system to provide a degree of independence.

Scope of the quarterly review

The quarterly review covers:

Tier 1 — Domain and cloud admin roles (highest priority):
  All accounts in Domain Admins group
  All accounts in Entra ID Global Administrator role
  All accounts in Entra ID Security Administrator role
  All accounts in Entra ID User Administrator role
  All accounts in Exchange Administrator role
  All accounts in SharePoint Administrator role
  All accounts with PAM vault admin access

Tier 2 — Elevated operational roles:
  All accounts in SIEM Administrator role (AT-AU 3.3.9)
  All accounts in Server Operators group
  All accounts with CUI file share full control (not just read)
  All accounts in the production-admin role (change management access)

Tier 3 — CUI access group (at minimum an annual review — quarterly recommended):
  All accounts in GRP-CUI-Access
  All accounts in GRP-CUI-FileShare-Write

Review procedure — step by step

Step 1 — Generate the current access list

# Export all members of privileged AD groups
$groups = @("Domain Admins","Server Operators","GRP-CUI-Access","[add all in scope]")
$results = foreach ($group in $groups) {
    Get-ADGroupMember -Identity $group -Recursive | 
    Get-ADUser -Properties DisplayName,EmailAddress,Enabled,LastLogonDate,Manager |
    Select-Object @{N="Group";E={$group}}, DisplayName, 
                  SamAccountName, EmailAddress, Enabled, 
                  LastLogonDate, @{N="Manager";E={$_.Manager}}
}
$results | Export-Csv -Path "PrivilegedAccountReview_[YYYY-QQ].csv" -NoTypeInformation

For Entra ID roles, export separately:

Entra ID → Roles and administrators → [each role] → Assignments → Download
Combine into the same spreadsheet, tagged with role name

Step 2 — Cross-reference against active employment

Cross-reference the account list against the HR system's active employee list. Flag any account that belongs to:

- A person no longer employed (leaver not fully de-provisioned — this is a finding)
- A contractor whose contract end date has passed
- A person on extended leave where elevated access is not required during absence
- A person who has changed role since last review and no longer requires the access

Step 3 — Review last logon dates

Flag accounts with no logon in the past 90 days. These may be:

Stale service accounts (verify they are still required)
Accounts for staff rarely in the office (verify they are current employees)
Orphaned accounts from incomplete de-provisioning

# Find accounts not logged in for 90+ days within the privileged account scope
$cutoff = (Get-Date).AddDays(-90)
$results | Where-Object {$_.LastLogonDate -lt $cutoff -or $_.LastLogonDate -eq $null}

Step 4 — Verify MFA configuration on all privileged accounts

For every privileged account (adm- prefix), verify in Entra ID Authentication Methods that a FIDO2 hardware key is registered and active. An admin account with only TOTP registered must be upgraded to FIDO2 before the next review period.

Step 5 — Verify no shared accounts exist

Check that no shared accounts (accounts not tied to a named individual) have privileged group membership. Any svc-, app-, or generic named account in a privileged group is a finding — service accounts should authenticate via Managed Identity or certificate, not via privileged AD group membership.

Step 6 — Make required changes

For every flagged item, take corrective action:

Remove departed employee accounts from privileged groups (and initiate full de-provisioning if not already complete)
Remove access from individuals who no longer require it (with IT Manager approval)
Disable stale accounts pending investigation

Step 7 — Document and file EV-D01

EV-D01 Quarterly Privileged Account Review — [YYYY-QQ]:

Review period: [Q start date] to [Q end date]
Conducted by: [IT Manager name]
Date of review: [date]

Summary:
  Total privileged accounts reviewed: [N]
  Active and appropriately configured: [N]
  Access removed (no longer required): [N] — [list accounts and reason]
  Accounts disabled (stale/orphaned): [N] — [list accounts and reason]
  MFA method upgraded to FIDO2: [N] — [list accounts]
  Findings requiring follow-up: [Y/N — if Y, list with ITSM reference]

Entra ID admin role holders confirmed:
  [List each admin role with the named individual holding it]

SIEM admin role holders confirmed:
  [Maximum 2: CISO + IT Manager only]

Break-glass envelope integrity confirmed: Y/N
  [Date envelope physically inspected]

IT Manager sign-off: _________________ Date: _________
CISO review and sign-off: _____________ Date: _________

File at: EV-D · Access Control Reviews → Privileged [YYYY-QQ]

Annual all-user access review (generates EV-D02)

Once per year, a broader access review covers all user accounts — not just privileged accounts. This review is less intensive per account than the quarterly privileged review but covers the full population.

Timing: Once per year — typically aligned with the management review 
        in Q4 to ensure outputs are available for the annual review

Scope:
  All active user accounts in the CUI-scope boundary
  Focus on: group memberships that grant access to Restricted or 
  CUI-scope resources

Procedure:
1. Export all user accounts and their group memberships:
   Get-ADUser -Filter * -Properties MemberOf | 
   Select SamAccountName, Name, Enabled, MemberOf

2. For each user: confirm their group memberships match their current role
   (cross-reference against HR-confirmed current role)

3. Flag: accounts with access to resources not matching their current role
   Flag: accounts for contractors — verify contract is still active

4. Request line manager confirmation:
   Send each manager the list of their direct reports' access
   Managers confirm each access level is still required
   (Use a structured form, not free-text email — audit trail requires 
   documented confirmation)

5. Remove any access confirmed as no longer required

6. File as EV-D02:
   Date, scope, method, findings, access removed, manager confirmation 
   references, IT Manager sign-off, CISO review

Evidence items summary — what to generate and when

This table is the operational checklist for IT Operations. Every evidence item that FC-03 and the AT-AC control family require is listed with its generation trigger, filing location, and the engineer responsible.

Evidence ID	What it is	Trigger	Owner	Filed at
EV-D03	JML provisioning log	Every joiner and mover event	IT Operations	EV-D → Access Control → JML Log
EV-D04	Leaver de-provisioning checklist	Every leaver event	IT Operations + HR	EV-D → Access Control → JML Log → Leaver Checklists
EV-D01	Quarterly privileged account review	Every quarter — Q1/Q2/Q3/Q4	IT Manager	EV-D → Access Control Reviews → Privileged [YYYY-QQ]
EV-D02	Annual all-user access review	Once per year — Q4	IT Manager	EV-D → Access Control Reviews → All-User [YYYY]
EV-D05	Quarterly MFA coverage report	Every quarter	IT Manager	EV-D → Access Control → MFA Status Report → [YYYY-QQ]
EV-D19	MFA configuration baseline	Annual review + on policy change	CISO	03 · Advanced Controls → AT-IA
EV-D20	Quarterly configuration audit	Every quarter — includes CA policy verification	IT Manager	EV-D → Config Management → Config Audits → [YYYY-QQ]

Evidence production calendar — quarterly schedule

Q1 (January–March):
  [ ] EV-D01 — Privileged account review Q1
  [ ] EV-D05 — MFA coverage report Q1
  [ ] EV-D20 — Config audit Q1 (includes CA policy check)

Q2 (April–June):
  [ ] EV-D01 — Privileged account review Q2
  [ ] EV-D05 — MFA coverage report Q2
  [ ] EV-D20 — Config audit Q2

Q3 (July–September):
  [ ] EV-D01 — Privileged account review Q3
  [ ] EV-D05 — MFA coverage report Q3
  [ ] EV-D20 — Config audit Q3

Q4 (October–December):
  [ ] EV-D01 — Privileged account review Q4
  [ ] EV-D02 — Annual all-user access review
  [ ] EV-D05 — MFA coverage report Q4
  [ ] EV-D20 — Config audit Q4
  [ ] EV-D19 — MFA and CA policy baseline annual review

Continuous (per event):
  [ ] EV-D03 — JML log entry within 24 hours of provisioning or mover
  [ ] EV-D04 — Leaver checklist filed within 5 working days of final day

Common implementation failures and how to prevent them

These are the access control findings most commonly raised in CMMC and ISO 27001 assessments. Each one is preventable through the procedures above.

Failure: shared accounts in audit logs. A svc-monitoring account or a admin local account appearing in authentication logs with no named individual attached means 3.3.2 (user traceability) and 3.9.1 (screening) cannot be satisfied for those events. Prevent by enforcing the naming convention and prohibiting service accounts from interactive login. Detect by searching SIEM for logon events from accounts matching the svc- prefix that also appear in security-sensitive event categories.

Failure: stale accounts not caught by quarterly review. A departed employee's account remaining active is a dual finding: 3.9.2 (protect CUI during personnel actions) and 3.1.5 (least privilege — an account for a non-employee has no legitimate access need). Prevent by ensuring the leaver process is always triggered from HR on the notification of departure, not on the final day. The quarterly review catches any that slip through.

Failure: CA policy with named location exclusion. A single excluded named location — "the office network is trusted, so we skip MFA from office IPs" — creates a bypass that directly defeats 3.5.3. An attacker who establishes a foothold inside the network or spoofs an office IP range can authenticate without MFA. Remove all named location exclusions from CA-002. MFA must apply everywhere, including the office.

Failure: EV-D03 not populated at time of provisioning. Assessors cross-reference JML log dates against AD account creation dates. If the JML log entry for a joiner is dated two weeks after the account creation date in AD, the log was retrospectively created and its value as evidence of the provisioning gate is undermined. Create the JML entry at the time of provisioning, not when the audit is approaching.

Failure: FIDO2 not deployed for privileged accounts. The quarterly privileged account review frequently surfaces admin accounts using Authenticator app TOTP rather than FIDO2. TOTP is acceptable for standard users but not for admin accounts — see AT-IA Section 3 for the rationale. Any admin account not on FIDO2 at the time of EV-D01 review must have the upgrade completed and documented within the quarter.

FC-03 IT Staff Technical Procedures — Owner: IT Manager. Related AT-[family] pages: AT-AC · Access Control, AT-IA · Identification and Authentication. Evidence register: EV-D03, EV-D04, EV-D01, EV-D02, EV-D05.