FC-03 · User Access Control
Confluence page header block
Page title: FC-03 · User Access Control
Parent page: 02 · Fundamental Controls
SCM variants: Default (all-staff) | isms-it-staff | isms-security
Page owner: IT Manager
Last reviewed: [DATE]
Next review: [DATE + 12 months]
Framework mapping panel
Visible to all users. Placed immediately below the page title as a metadata callout.
| Field | Value |
|---|---|
| CMMC Level 1 practices | AC.L1-3.1.1 · AC.L1-3.1.2 · IA.L1-3.5.1 · IA.L1-3.5.2 |
| Cyber Essentials domain | User Access Control — all five Cyber Essentials requirements |
| DEFSTAN 05-138 | Profile 0 (Baseline) — §Access Control and §Identification |
| ISO 27001 Annex A | 5.15 (Access control) · 5.16 (Identity management) · 5.17 (Authentication) · 8.2 (Privileged access) · 8.5 (Secure authentication) |
| Related advanced pages | AT-AC · Access Control · AT-IA · Identification and Authentication |
| All-staff guidance | 04 · User Guidance Hub → Passwords and MFA |
| Evidence items (IT/Security) | EV-D01 · EV-D02 · EV-D03 · EV-D04 · EV-D05 · EV-D19 |
Why user access control is the first Fundamental Control assessed
All-staff layer — visible to everyone.
When an assessor arrives to verify our CMMC, Cyber Essentials, or DEFSTAN compliance, user access control is evaluated before almost anything else. The reason is logical: every other technical security control — the firewall, the malware protection, the patch management programme — only protects information from people who are not supposed to have it. User access control determines who is supposed to have it. If the access control foundation is wrong, every control above it is weakened.
For us specifically, four CMMC Level 1 practices, the entire Cyber Essentials User Access Control domain, and the DEFSTAN Profile 0 access requirements all converge on the same operational question: do only the right people, in the right circumstances, using the right devices, have access to our systems and information?
This page explains what that means for everyone in the organisation, and — in the sections below visible to IT Operations and the security team — exactly how it is implemented and evidenced.
All-staff layer
No SCM variant wrapper — visible to isms-all-staff, isms-it-staff, and isms-security.
What user access control means in practice
User access control is not a single setting or a single policy. It is the combination of four things working together:
Unique identity — every person has their own account. Accounts are never shared between individuals, and you are never permitted to use someone else's account, regardless of the circumstances.
Authentication — proving you are who you say you are before access is granted. Your password is the primary factor. Your MFA (the notification on your phone or the code from your authenticator app) is the second factor. Both are required.
Authorisation — controlling what an authenticated person can actually access. Having a valid account does not give you access to everything. You have access to the specific systems, files, and applications your role requires, and nothing more.
Accountability — recording what was accessed, when, and by whom. Your account actions are logged. This protects you as much as it protects the organisation — if something goes wrong, the logs confirm what actually happened.
The four CMMC Level 1 practices — what they mean for you
These four practices are the US Department of Defense's baseline access control requirements for any organisation that handles Federal Contract Information. They are not complex in concept — they are the minimum any organisation should be doing.
AC.L1-3.1.1 — Authorised users, processes, and devices only. Only people who have been authorised may access our systems. Authorisation means your account exists because your role was reviewed, your screening was completed, and IT Operations was instructed by HR to provision access. Access granted informally — "just use my login," "I'll set up a temporary account without going through the proper process" — does not satisfy this requirement and is a policy breach.
AC.L1-3.1.2 — Only the transactions and functions authorised users are permitted to execute. Having an account does not give you unlimited authority within that account. You can do what your role requires. You cannot access HR payroll data because you found a link to it. You cannot install software because your account has the technical ability to do so. The principle is least privilege: the minimum access necessary to do your job, nothing more.
IA.L1-3.5.1 — Identify information system users, processes, and devices. Every action on our systems is attributable to a named individual. There are no anonymous accounts, no shared accounts, and no unattributed processes on CUI-scope systems. Your username is your identity on those systems, and the logs record your actions against your identity.
IA.L1-3.5.2 — Authenticate users, processes, and devices before allowing access. Authentication must happen before access is granted — not after, not occasionally, not for some systems but not others. Every login to every CUI-scope system requires authentication. The organisation implements multifactor authentication for all CUI-scope access, which means your password plus your authenticator app or hardware token.
Cyber Essentials — the five user access control requirements
Cyber Essentials is the UK government-backed certification that every supplier to central government and to many defence contracts is required to hold. Its User Access Control domain has five requirements that overlap significantly with the CMMC Level 1 practices but are expressed in slightly different operational terms.
Requirement 1: User accounts are created for named, individual people. No shared accounts. No group accounts. No "admin" accounts used by multiple engineers. Every account is one person.
Requirement 2: Special access (administrator accounts) is limited to those who need it for their job. Administrator accounts — accounts with the ability to install software, change system settings, or manage other accounts — are held only by people whose role specifically requires that capability. No standard user holds an administrator account. IT Operations staff who need administrative access have a separate administrator account distinct from their standard day-to-day account. They use the standard account for normal work and the administrator account only when performing administrative tasks.
Requirement 3: Accounts are removed or disabled when no longer required. When you leave the organisation, your account is disabled on your final day. When you change roles and no longer need access to a specific system, that access is removed. Accounts are not left dormant — they are actively managed throughout their lifecycle.
Requirement 4: Passwords must be of sufficient strength. The minimum password length for all accounts is 16 characters. Passwords must be unique to this organisation — do not reuse passwords from personal accounts. A passphrase (four or more random words) is easier to remember and is stronger than a shorter complex password.
Requirement 5: MFA is used where available. Multifactor authentication is required for all access to organisation systems. This applies to cloud services (Microsoft 365, cloud platforms), VPN, and all CUI-scope applications. The authenticator app on your phone is the standard second factor. Hardware security keys are used for administrator accounts and high-privilege access.
DEFSTAN Profile 0 — baseline access requirements for defence work
DEFSTAN 05-138 defines security requirements for suppliers handling UK government and MOD information. Profile 0 is the baseline profile — the minimum required for anyone handling OFFICIAL-tier information, which includes most of what we handle on defence contracts.
Profile 0 §Access Control requires:
Named accounts for all personnel. Every individual with access to systems handling OFFICIAL information must have a named, individual account. This includes contractors, consultants, and personnel from partner organisations who are individually granted system access.
Account lifecycle management tied to employment status. Access provisioning must occur only after employment and screening obligations are met. Access revocation must occur at the point of departure, not after. The DEFSTAN requirement is explicit: access must not persist beyond the end of the individual's authorised engagement with the project.
Password controls proportionate to the information sensitivity. For OFFICIAL-tier access, password length and complexity requirements must meet a defined minimum standard. The organisation's 16-character minimum passphrase standard exceeds the DEFSTAN baseline requirement and is therefore compliant.
Restriction of access to what the role requires. Personnel should be able to access only the information necessary for their assigned role on the contract. Cross-contract access — where personnel working on one contract can access information from a different contract — is only permitted where specifically authorised by the contracting authority.
Audit trail for access to OFFICIAL information. Access to systems holding OFFICIAL information must be logged and logs must be retained. The SIEM logging described in OP-03 and AT-AU satisfies this requirement. The logs must be available on request from the contracting authority.
Your access control obligations — what you must do
These obligations apply to everyone. They are a condition of your employment and your access to organisation systems.
Never share your credentials. Your username and password are yours alone. No IT support engineer, no manager, no colleague has a legitimate reason to ask for your password. If someone asks, decline and report it to IT Operations.
Never use another person's account. Not even with their explicit permission. Not even in an emergency. Not even briefly. If you need access to something and cannot get it, the solution is to request access through the proper process.
Report any unexpected account activity immediately. If you receive an MFA notification you did not initiate, if you see a login from a location you were not in, if a system behaves as though someone else is logged in as you — report it to the security team immediately. Do not wait.
Only approve MFA requests you initiated. An MFA notification arrives because someone entered your credentials and is waiting for you to approve their login. If you are not currently logging in to anything, that notification is an attacker with your password. Deny it. Change your password. Report it.
Lock your screen whenever you leave your workstation. Windows: Windows key + L. Mac: Control + Command + Q. An unlocked screen with your session active is equivalent to leaving your account open for anyone who walks past.
Report your departure or role change promptly. If you are leaving the organisation or changing roles, ensure HR has recorded it so that your access can be adjusted promptly. Do not assume it will happen automatically.
Do not use personal devices for work that involves CUI. Personal devices are not enrolled in the MDM, do not have the security baseline applied, and are not monitored. CUI accessed on a personal device is outside the organisation's controls and is a policy breach.
IT-staff layer
SCM variant: isms-it-staff — visible to isms-it-staff and isms-security.
{scroll-content:variant=isms-it-staff}
Technical implementation — IT Operations
This section provides the operational implementation detail for all four CMMC Level 1 practices, the Cyber Essentials UAC requirements, and the DEFSTAN Profile 0 access requirements. The full implementation procedures — including the complete JML workflow, privileged account management, MFA configuration, and evidence generation — are documented in the IT Operations Procedures Library (OP-01) and the FC-03 IT Staff Technical Procedures page. This section provides the cross-referenced summary and the specific implementation points unique to the fundamental tier compliance obligations.
AC.L1-3.1.1 — Technical implementation
What assessors test for this practice: Assessors will request a list of all accounts with access to CUI-scope systems and cross-reference it against the HR active employee list. They will attempt to identify: accounts with no corresponding active employee; accounts provisioned before screening was completed; shared or generic accounts on CUI-scope systems.
Technical enforcement mechanisms:
Entra ID / Active Directory:
Every human account is in the format: firstname.lastname@[domain]
No shared mailboxes or group accounts are used for interactive login
All accounts map to a specific individual via the manager attribute
Contractor accounts have an expiry date set at creation (= contract end date)
Orphaned account detection:
Monthly: cross-reference Entra ID active accounts against HR system
PowerShell (for export):
Get-AzureADUser -All $true |
Where-Object {$_.AccountEnabled -eq $true} |
Select-Object DisplayName, UserPrincipalName,
@{N="LastSignIn";E={$_.SignInActivity.LastSignInDateTime}} |
Export-Csv "Active-Accounts.csv"
Cross-reference against HR export: any account in Entra ID not
in the HR "current employees" list is an orphan — investigate immediately
Network device access:
All network device management accounts must be individual, named accounts
Shared "admin" accounts on network devices are not permitted
If the network device does not support individual accounts:
Document in EV-D08 (exception register) with compensating controls
(shared password rotated after every use, stored in PAM)
Service accounts:
Named with svc-[function] convention, not human names
Documented in asset register with owning system and owning engineer
No interactive login permitted (Login Denied attribute where supported)
Reviewed quarterly as part of EV-D01 privileged account review
Provisioning gate — the authorisation before access:
No account is created without an approved ITSM onboarding request
ITSM request must show HR confirmation that pre-employment screening is complete
The date the account was created (from AD audit log) must be on or after
the screening completion date (from EV-B08)
The JML log (EV-D03) records this gate for every provisioning event
PowerShell to extract AD account creation dates:
Get-ADUser -Filter * -Properties WhenCreated |
Select-Object Name, SamAccountName, WhenCreated |
Sort-Object WhenCreated -Descending
Cyber Essentials specific — user account register:
Cyber Essentials requires that the organisation can demonstrate it maintains a register of all user accounts and that this register is kept current. The combination of Entra ID (as the live user directory) and EV-D03 (the JML log recording every provisioning event) constitutes the account register. During a Cyber Essentials assessment, the assessor will ask to see:
- The current list of active user accounts
- Evidence that accounts are removed promptly when users leave (EV-D04)
- Evidence that contractor accounts have expiry dates
DEFSTAN specific — cross-contract access restriction:
For DEFSTAN-scope contracts, verify that CUI group membership is contract-specific where required. If the contracting authority has specified that only named personnel may access contract-specific information, a dedicated security group must exist for that contract and only named individuals are members.
Example group structure for DEFSTAN contract isolation:
GRP-CUI-Access (general CUI access — all CUI-cleared staff)
GRP-CONTRACT-[MOD-REF]-Access (contract-specific access — named personnel only)
Contract-specific SharePoint sites: permission granted to
GRP-CONTRACT-[MOD-REF]-Access, NOT to GRP-CUI-Access
Any change to contract group membership requires CISO approval
and is logged in EV-D03
AC.L1-3.1.2 — Technical implementation
What assessors test for this practice: Assessors will attempt to access resources beyond their test account's role. They will review group memberships to identify accounts with access that appears disproportionate to their stated role. They will check for accounts in multiple, logically incompatible access groups (e.g. both Finance-Read-Only and Finance-Admin).
Least privilege enforcement:
Role-based access group structure:
Access is always via security group membership, never direct ACL assignment
Reasons: groups are auditable; groups are revocable in bulk;
groups appear in access reviews clearly
Standard role groups:
GRP-ROLE-Engineering-Standard (file server read/write for engineering paths)
GRP-ROLE-Finance-Standard (file server read/write for finance paths)
GRP-ROLE-HR-Standard (file server read/write for HR paths)
GRP-ROLE-AllStaff-SharedDrives (shared areas all roles can read)
GRP-CUI-Access (CUI-scope systems — requires CISO approval)
No staff member should be in two incompatible role groups:
Example incompatibility: GRP-Finance-Standard AND GRP-Finance-Admin
Example incompatibility: GRP-HR-Standard AND GRP-Finance-Standard
(HR staff do not need Finance file access and vice versa)
Any cross-group membership: documented justification in EV-D03/EV-D01
Separation of duties enforcement:
No individual has both the ability to request access AND approve access
No individual has both the ability to initiate payments AND approve payments
Where system capability permits: enforce SoD via access control policy
Where not technically enforceable: compensating control = EV-D01 quarterly review
SharePoint permissions structure:
Site permissions: via security group only (not individual user)
No "Everyone" or "Everyone except external users" permissions on CUI sites
External sharing: disabled on all CUI-scope SharePoint sites
Guest access: disabled for CUI sites regardless of what Azure tenant-level
settings allow (override at site level)
Cyber Essentials specific — administrator account separation:
Cyber Essentials explicitly requires that administrator accounts are separate
from standard user accounts. The dual-account model (documented in FC-03 IT
Procedures) satisfies this:
adm-firstname.lastname accounts: used only for administrative tasks
firstname.lastname accounts: used for all standard work
Assessors check:
No standard user accounts are in Domain Admins or local Administrators group
No administrator accounts are used for email, web browsing, or standard apps
Verification:
Get-ADGroupMember "Domain Admins" | ForEach-Object {
Get-ADUser $_.SamAccountName -Properties Description |
Select-Object Name, SamAccountName, Description
}
Expected: all entries should have "ADM" prefix or be service accounts
Any firstname.lastname account in Domain Admins: immediate finding — remove
DEFSTAN specific — access proportionate to clearance level:
Profile 0 requires that access to OFFICIAL information is proportionate
to the individual's screening level
Verification mapping:
OFFICIAL general access → BPSS screened minimum → GRP-CUI-Access eligible
OFFICIAL-SENSITIVE access → SC clearance minimum → GRP-CONTRACT-[MOD-REF]-Access
Audit: quarterly, confirm that no GRP-CONTRACT-[SC-required] member has
their screening record showing BPSS-only in EV-B08
If found: immediately remove from group; notify CISO; notify contracting authority
IA.L1-3.5.1 — Technical implementation
What assessors test for this practice: Assessors will check that every interactive session on every CUI-scope system produces a log entry with an individual user identifier. They will look for systems where authentication is not required, where shared credentials are used, or where logs show unattributed access.
Identity uniqueness enforcement:
Unique identifier enforcement:
UPN format: firstname.lastname@[domain]
SAMAccountName: f.lastname (15-char limit — use suffix for collisions)
Employee ID attribute: populated from HR system at provisioning
No two accounts share an identifier:
UPN uniqueness: enforced by Active Directory (cannot create duplicate UPN)
SAMAccountName uniqueness: enforced by AD
Display name collisions (two John Smiths): use middle initial or suffix
john.smith@[domain] (first hire)
john.a.smith@[domain] (second hire)
Document collision resolution in EV-D03
Audit logging that produces attributable events:
Every authentication event records:
- User identifier (UPN or SAMAccountName)
- Source device identifier (device name or IP)
- Timestamp (UTC, NTP-synchronised)
- Success or failure
- Application or service accessed
Windows audit event coverage (GPO-enforced):
Event 4624: Successful logon — includes LogonType, AccountName, WorkstationName
Event 4625: Failed logon — includes failure reason
Event 4648: Logon with explicit credentials (RunAs events)
Event 4768: Kerberos TGT requested — user identity at domain level
Entra ID sign-in logs:
All interactive and non-interactive sign-ins
UserPrincipalName, IPAddress, DeviceDetail, AppDisplayName
Conditional Access policy applied / not applied
MFA detail (required / satisfied / not required — latter should not appear
for CUI-scope apps)
Process and service account identification:
Service accounts use the svc-[function]@[domain] naming convention
Every automated process accessing CUI-scope systems uses a named service account
No process accesses CUI-scope systems using a human user account
Service accounts are documented in the asset register with:
Account name
Owning system / application
Owning engineer
Authentication method (certificate / managed identity / password in PAM)
Access groups
Device identification:
All CUI-scope devices must be identifiable in logs
Windows: computer name is included in audit log event 4624
macOS: device name from MDM is included in Entra ID sign-in log
Network devices: hostname included in all syslog events
Cloud resources: resource name / ARN / resource ID in CloudTrail / Activity Log
Device naming convention:
Windows workstations: WS-[DEPT]-[ASSET#] (e.g. WS-ENG-0042)
Servers: SRV-[FUNCTION]-[#] (e.g. SRV-CUIFILE-01)
Network devices: [TYPE]-[LOCATION]-[#] (e.g. FW-DC-01, SW-FLOOR2-03)
Unnamed or generically named devices on CUI-scope networks: finding
Audit device names quarterly via MDM inventory and network discovery
IA.L1-3.5.2 — Technical implementation
What assessors test for this practice: Assessors will attempt to access CUI-scope systems without authenticating. They will check whether MFA can be bypassed. They will review Conditional Access policy configuration to confirm there are no gaps. They will test whether legacy authentication is blocked.
Authentication enforcement — complete technical specification:
The complete MFA configuration is documented in FC-03 IT Staff Technical
Procedures → MFA Configuration section. The following summarises the
implementation points most relevant to the fundamental tier assessment.
Authentication before access — the gate cannot be bypassed:
Conditional Access Policy CA-002 applies to all users, all apps, all locations
No named location exclusions (office IP ranges, trusted networks)
No user exclusions except documented break-glass accounts
Common bypass attempt by assessors:
Using a legacy email client (IMAP, POP3) with username/password only
Expected result: "Authentication failed — your client doesn't support
modern authentication or doesn't meet our security requirements"
Verify CA-003 (legacy auth block) is working:
Monitor Entra ID sign-in logs:
Client app = "Other clients" + Status = "Success" → CA-003 misconfiguration
Expected: zero successful legacy auth events
MFA requirement — never skipped for CUI scope:
Entra ID Conditional Access Policy CA-002 requires MFA for all cloud app access
On-premises applications that are not Azure AD-integrated must use:
Either: RADIUS with NPS Extension (adds MFA to RADIUS authentication)
Or: Application Proxy (integrates legacy apps with Entra ID auth)
Or: If neither is feasible: document as exception in EV-D08 with
compensating controls and CISO approval
Applications that cannot support MFA must not access CUI
This is a hard line — there is no "MFA not available but it's OK" for CUI scope
Network access authentication:
VPN: authenticated via certificate (device) + Entra ID SAML (user) + MFA
Wi-Fi: WPA3-Enterprise with 802.1X — requires domain credentials + device cert
(No open Wi-Fi, no WPA2-PSK on CUI-scope network segments)
Network device management (SSH): certificate-based auth + FIDO2 via PAM
Any unauthenticated network access to CUI-scope segments: immediate finding
Cyber Essentials specific — password complexity enforcement:
Cyber Essentials requires that accounts are protected by passwords
that meet a minimum standard. The standard allows two approaches:
Approach A (two-factor authentication enabled):
When MFA is enforced, Cyber Essentials does not mandate a specific
minimum password length for standard accounts (MFA compensates)
The organisation uses MFA-enabled approach AND 16-character minimum passphrase
This exceeds the Cyber Essentials requirement
Approach B (no MFA — longer passwords required):
Without MFA: minimum 12 characters + no lockout → 8 chars acceptable
only with lockout after 10 attempts
This approach does NOT apply to CUI-scope accounts — MFA is mandatory
Assessor verification:
FGPP query: Get-ADFineGrainedPasswordPolicy -Identity FGPP-Standard-Users
MinPasswordLength should show 16
LockoutThreshold should show 5
LockoutDuration should show 00:15:00
DEFSTAN Profile 0 — session management requirements:
Profile 0 requires that sessions are locked after a period of inactivity
Required controls:
Workstation inactivity timeout: 15 minutes → lock screen (not logoff)
GPO: Computer Configuration → Security Options →
Machine inactivity limit: 900 seconds
MDM (macOS): screensaver with password required, loginWindowIdleTime: 900
Required controls for remote access sessions:
VPN idle session timeout: 60 minutes of inactivity → terminate
RDP/remote session idle: 30 minutes → disconnect (not log off — preserves
work state while securing the session)
Verify VPN timeout: [vendor-specific command to display session timeout policy]
Verify RDP timeout:
GPO: Computer Configuration → Administrative Templates →
Windows Components → Remote Desktop Services →
RD Session Host → Session Time Limits →
Set time limit for active but idle RD sessions: 30 minutes
Quarterly access review procedure — IT staff reference
The quarterly privileged account review (EV-D01) and annual all-user access review (EV-D02) are the primary evidence items for ongoing compliance with all four CMMC Level 1 practices, all five Cyber Essentials UAC requirements, and DEFSTAN Profile 0 account lifecycle obligations.
The complete procedure is in FC-03 IT Staff Technical Procedures → Quarterly Privileged Account Review. The following are the specific checks required for fundamental tier compliance:
Cyber Essentials-specific checks within the quarterly EV-D01 review:
Check CE-UAC-1: Shared accounts audit
Search for accounts with more than one named custodian in the JML log
Search for accounts with generic Display Names (Admin, Helpdesk, Test, etc.)
Acceptable result: zero shared accounts on CUI-scope systems
Check CE-UAC-2: Administrator account separation
List all members of Domain Admins, local Administrators groups
Verify every member follows the adm- naming convention
Verify no adm- account has a configured mailbox
(Admin accounts must not be used for email)
Acceptable result: zero firstname.lastname accounts in privileged groups
Check CE-UAC-3: Departed user accounts
Cross-reference all active accounts against HR active employee list
Any active account with no corresponding HR record → immediate disable
Flag for CISO review — potential de-provisioning failure
Check CE-UAC-4: Contractor account expiry
Filter: Get-ADUser -Filter {AccountExpires -ne "0" -and AccountExpires -ne
"9223372036854775807"} -Properties AccountExpirationDate
Verify all contractors have an expiry date
Verify no expiry date has passed without the account being disabled
Any expired account still enabled: immediate finding
Check DEFSTAN-P0-1: Clearance level vs access level
For all members of GRP-CONTRACT-[SC-required] groups:
Cross-reference each member against the clearance register (AT-PS)
Confirm SC clearance is current and has not lapsed
Any member with lapsed or absent clearance: remove immediately; notify CISO
EV-D01 record: document results of all CE and DEFSTAN checks alongside
the standard privileged account review outputs
Evidence generation — this control family
| Evidence ID | What to produce | When | How | Filed at |
|---|---|---|---|---|
| EV-D03 | JML provisioning log entry | Every joiner and mover event | ITSM record cross-referenced to AD account creation; include screening confirmation reference | EV-D → Access Control → JML Log |
| EV-D04 | Leaver de-provisioning checklist | Every leaver event | Three-section checklist (HR / IT / CISO) signed within 5 working days | EV-D → Access Control → JML Log → Leaver Checklists |
| EV-D01 | Quarterly privileged account review | Quarterly | PowerShell export + cross-reference; includes CE and DEFSTAN-specific checks | EV-D → Access Control Reviews → Privileged [YYYY-QQ] |
| EV-D02 | Annual all-user access review | Annual (Q4) | Full user population; line manager confirmation | EV-D → Access Control Reviews → All-User [YYYY] |
| EV-D05 | Quarterly MFA coverage report | Quarterly | Entra ID Authentication Methods report + six-check procedure | EV-D → Access Control → MFA Status → [YYYY-QQ] |
| EV-D19 | MFA and access control baseline | Annual review + on policy change | Documented Conditional Access policy configuration | AT-IA / EV-D → Config Management |
| EV-B08 | Pre-employment screening register | Per hire; annual review | HR-maintained; screening completion date vs provisioning date | EV-B → Personnel Security |
{scroll-content}
Security-staff layer
SCM variant: isms-security — visible to isms-security only.
{scroll-content:variant=isms-security}
Evidence currency dashboard
Review this panel at the beginning of each month. Update Status and Last produced fields after each evidence production cycle.
| Evidence ID | Item | Required frequency | Last produced | Status | Owner |
|---|---|---|---|---|---|
| EV-D03 | JML provisioning log — all joiners and movers | Per event (within 24 hours) | [date] | [Current / Gap] | IT Operations |
| EV-D04 | Leaver de-provisioning checklist | Per leaver (within 5 working days) | [date of most recent leaver] | [Current / Gap] | IT Operations + HR |
| EV-D01 | Quarterly privileged account review | Quarterly | [date] | [Current / Overdue] | IT Manager |
| EV-D02 | Annual all-user access review | Annual | [date] | [Current / Overdue] | IT Manager |
| EV-D05 | Quarterly MFA coverage report | Quarterly | [date] | [Current / Overdue] | IT Manager |
| EV-D19 | Access control configuration baseline | Annual | [date] | [Current / Overdue] | CISO |
| EV-B08 | Screening register — annual clearance expiry review | Annual | [date] | [Current / Overdue] | HR Manager |
Evidence dependencies for this control family:
EV-D03 is upstream of everything. If EV-D03 is incomplete or has gaps, EV-D01 and EV-D02 lose their evidentiary value — the access reviews depend on the JML log accurately reflecting all provisioning events. Confirm EV-D03 is gapless before relying on the quarterly review records.
EV-B08 (screening register) must be cross-referenced against EV-D03 before any assessment. The screening completion date in EV-B08 must precede the account creation date in EV-D03 for every entry. If any account creation date predates its corresponding screening completion date, this is a 3.9.1 finding that also compromises the AC.L1-3.1.1 evidence chain.
MITRE ATT&CK context — what this control family detects
User access controls are primarily detective and preventive for the following technique categories. When reviewing EV-F01 (monthly SIEM log review) and EV-F07 (privileged session review), actively look for indicators of these techniques.
T1078 — Valid Accounts (all sub-techniques): The most common initial access technique for organisations at our threat tier. An attacker who has obtained valid credentials (via phishing, credential stuffing, or a previous breach) attempts to authenticate as a legitimate user. The controls in this family detect this through: MFA denial events (the attacker has the password but not the phone); authentication from unusual geographic locations or devices; authentication at times inconsistent with the user's normal pattern; and authentication velocity (the same account attempting to authenticate from multiple geographic locations within an impossible timeframe).
SIEM rules monitoring for T1078:
- CA-002 MFA failure on valid credentials (authentication blocked by CA, not by bad password)
- Sign-in from country not in user's 90-day location history
- Sign-in from device not enrolled in MDM (Compliant: No in Entra ID sign-in log)
- Account active during a period when the user is on recorded leave
T1136 — Create Account: An attacker with sufficient privileges creates a new account to maintain persistence after their initial access is contained. The preventive control is the ITSM gate (no account without an approved request). The detective control is the SIEM alert for new account creation (AD Event 4720) that does not correspond to an approved ITSM ticket created within the past 24 hours.
Detection: cross-reference AD Event 4720 against ITSM provisioning tickets. Any account created outside the ITSM process is either a process failure or a security incident.
T1098 — Account Manipulation: Modifying existing account permissions or properties to expand access without creating a new account. Specifically: adding a standard account to a privileged group (Event 4728 — member added to security group), modifying group policy to weaken access controls, or changing an account's password to maintain persistence.
Detection: SIEM alert on Event 4728 for privileged groups (Domain Admins, Server Operators, GRP-CUI-Access) not corresponding to an approved ITSM mover request. SIEM alert on security policy changes (Event 4719) not in a documented maintenance window.
T1531 — Account Access Removal (defensive disruption): An attacker disabling or deleting accounts to disrupt response and investigation. This is less common but appears in some ransomware attack patterns where the attacker disables IT administrator accounts before deploying ransomware to slow the response.
Detection: Event 4725 (account disabled) or Event 4726 (account deleted) for accounts in the IT Operations or CISO role, outside the normal leaver process, not corresponding to an ITSM ticket.
Control effectiveness assessment — quarterly
Complete this table each quarter as part of the internal assessment programme (AT-CA 3.12.1). The Security Analyst completes the technical test results. The CISO reviews and signs off.
| Control | Test | Last tested | Result | Trend | Notes |
|---|---|---|---|---|---|
| No shared accounts on CUI systems | Query AD for accounts without a manager attribute or with generic display names | [date] | Pass / Fail | ↑↓→ | |
| All CUI-scope users enrolled in MFA | EV-D05 Check 1 — Entra ID MFA registration report | [date] | [X%] — Pass if 100% | ↑↓→ | |
| Legacy authentication blocked | EV-D05 Check 3 — successful legacy auth events = zero | [date] | Pass / Fail | ↑↓→ | |
| CA policy applied to all CUI app sign-ins | EV-D05 Check 2 — zero successful sign-ins with CA not applied | [date] | Pass / Fail | ↑↓→ | |
| No standard account in privileged groups | Quarterly EV-D01 check CE-UAC-2 | [date] | Pass / Fail | ↑↓→ | |
| All leaver accounts disabled same day | EV-D04 review — timestamp check on account disable vs final working day | [date] | [X of X leavers] | ↑↓→ | |
| Session lock after 15-min inactivity | GPO test: allow workstation to idle for 16 minutes — confirm screen locked | [date] | Pass / Fail | ↑↓→ | |
| DEFSTAN clearance level vs access level | EV-D01 check DEFSTAN-P0-1 | [date] | Pass / Fail | ↑↓→ | |
| No accounts active beyond employment end | EV-D01 cross-reference against HR active list | [date] | Pass / Fail | ↑↓→ | |
| MFA denial rate for unexpected requests | SIEM: MFA denied / (MFA approved + MFA denied) for the quarter | [date] | [%] | ↑↓→ | High denial rate may indicate active attack; low may indicate fatigue |
Assessor preparation — C3PAO, Cyber Essentials, and DEFSTAN
The following prepares for the access control examination under three simultaneous assessment frameworks. All three frameworks examine this control family but with different emphases.
C3PAO examination preparation (CMMC Level 1)
AC.L1-3.1.1 — what the assessor will request and test:
Documents to prepare before assessment day:
[ ] Current active account list (Export from Entra ID or AD — date-stamped)
[ ] HR active employee list (current as of same date as account list)
[ ] EV-D03 JML log — last 12 months complete (no date gaps)
[ ] EV-D01 — last 4 quarters (quarterly review records)
[ ] EV-B08 screening register — all current CUI-scope staff
Demonstration to prepare:
[ ] Show ITSM provisioning ticket for a recent joiner — confirm screening
confirmation field is populated with HR reference
[ ] Show AD account creation date for same joiner — confirm it is after
screening completion date in EV-B08
[ ] Show contractor account — confirm expiry date attribute is set
Interview talking points (IT Manager should be prepared to explain):
"When a new person starts, what is the process before their account is created?"
→ Walk through: HR initiates ITSM request → IT Operations checks screening gate
→ account created → access provisioned to role groups → JML log entry
"How do you know if someone has left and their account is still active?"
→ EV-D01 quarterly cross-reference against HR; SIEM alert on dormant accounts;
EV-D04 leaver checklist prevents it happening if process is followed
AC.L1-3.1.2 — what the assessor will request and test:
Documents to prepare:
[ ] Role-to-access-group mapping document (which groups do which roles get?)
[ ] EV-D01 showing SoD check results for the most recent quarter
[ ] Any documented exceptions to least privilege (EV-D08) with justification
Demonstration to prepare:
[ ] Show group membership for a standard user account
Confirm: only in role-appropriate groups; not in any privileged groups
[ ] Show group membership for an IT Operations engineer
Confirm: has adm- account separate from firstname.lastname account
Confirm: adm- account is not used for email (no mailbox)
[ ] Attempt to access a resource with a standard test account that
the account's role does not require
Expected: access denied
Interview talking point:
"If someone needs temporary access to a resource outside their normal role,
what is the process?"
→ ITSM request → IT Manager approval → time-limited group membership →
access revoked after stated period → logged in EV-D03 as mover event
IA.L1-3.5.1 and IA.L1-3.5.2 — assessor examination:
Documents to prepare:
[ ] EV-D05 — last two quarters of MFA coverage reports
[ ] Conditional Access policy export (from Entra ID — JSON or screenshot)
[ ] EV-D19 — access control configuration baseline confirming CA policy settings
[ ] SIEM log evidence showing CA policy applied to CUI-scope app sign-ins
(sample of sign-in log entries for the past 30 days)
Demonstration to prepare:
[ ] Open Entra ID sign-in logs — show that all successful CUI app logins
have "Conditional Access: Success" and "MFA: satisfied"
[ ] Attempt to access a CUI-scope application from a non-enrolled device
Expected: blocked by CA-002 (Compliant device required)
[ ] Attempt to authenticate using legacy protocol (e.g. basic auth via curl)
Expected: blocked by CA-003 (legacy auth block)
[ ] Show FGPP settings confirming 16-character minimum:
Get-ADFineGrainedPasswordPolicy FGPP-Standard-Users |
Select MinPasswordLength, LockoutThreshold, LockoutDuration
Common finding to prevent — the CA gap:
CA policies with named location exclusions (office IP trusted → MFA skipped)
are one of the most common IA.L1-3.5.2 findings. Confirm:
Entra ID → Security → Conditional Access → Named Locations
Every named location: confirm it is not used as an exclusion in CA-002
If it is: this is a finding — remove the exclusion before assessment
Cyber Essentials assessor preparation
Cyber Essentials assessments for this domain typically consist of a self-assessment questionnaire (for CE) or a technical verification (for CE+). The following maps the five UAC requirements to the specific evidence and system demonstrations.
CE Requirement 1 — Named, individual accounts:
Self-assessment answer: Yes — all accounts are individual named accounts
CE+ technical verification:
Assessor will request account list — confirm no generic names (Admin, User, etc.)
Assessor will attempt to identify shared accounts in SIEM logs
Evidence: EV-D03 (every account has a named provenance)
CE Requirement 2 — Limited administrator access:
Self-assessment answer: Yes — administrators use separate admin accounts
CE+ technical verification:
Assessor will request list of all administrator accounts
Confirm: all admin accounts follow adm- convention
Confirm: no adm- accounts have email configured
Confirm: standard accounts are not local administrators on workstations
Verify standard accounts are not local admins:
Invoke-Command -ComputerName [sample-workstations] -ScriptBlock {
Get-LocalGroupMember -Group "Administrators"
}
Expected output: only SYSTEM, the adm- account, and the domain group
for approved admin delegation — never the user's firstname.lastname account
CE Requirement 3 — Account removal when no longer required:
Self-assessment answer: Yes — accounts are disabled on final working day
CE+ technical verification:
Assessor will request list of accounts disabled in the past 12 months (leavers)
Assessor will cross-reference against publicly available HR information
(LinkedIn, company website) to check for former employees with active accounts
Evidence: EV-D04 leaver checklists — timestamp confirms same-day disable
CE Requirement 4 — Password strength:
Self-assessment answer: Yes — 16-character minimum enforced via FGPP
CE+ technical verification:
Assessor will attempt to set a short password on a test account
Expected: rejected by password policy
Verify: Get-ADFineGrainedPasswordPolicy FGPP-Standard-Users
CE Requirement 5 — MFA where available:
Self-assessment answer: Yes — MFA mandatory for all cloud/remote access
CE+ technical verification:
Assessor will attempt to access cloud services without completing MFA
Expected: blocked by Conditional Access
Assessor will check for legacy auth bypass capability
Expected: blocked by CA-003
DEFSTAN assessment preparation
DEFSTAN assessments are conducted by the contracting authority (usually DIO/DE&S or the prime contractor's security team). Profile 0 access control examination focuses on:
What DEFSTAN assessors examine for Profile 0 access control:
1. Named account for everyone with OFFICIAL system access
Prepare: current user list for systems handling DEFSTAN-contract OFFICIAL information
Show: each account maps to a named individual with current employment status
2. Account tied to employment/engagement status
Prepare: process description for how accounts are created and removed
Show: EV-D03 (provisioning on engagement start) and EV-D04 (revocation on end)
Key question: "What happens on the day a person's engagement ends?"
Answer: account disabled same day; card revoked; data custody transferred;
DEFSTAN contracting authority notified if clearance-held personnel
3. Access restricted to what the role requires for that specific contract
Prepare: group membership for any DEFSTAN-contract-specific access groups
Show: GRP-CONTRACT-[MOD-REF]-Access membership is only named personnel
approved by the contracting authority for that contract
Show: personnel not named on the contract cannot access contract-specific SharePoint
4. Audit trail available
Prepare: sample sign-in log showing access to DEFSTAN-contract SharePoint site
Show: log entry includes individual UPN, timestamp, and resource accessed
Assessor may request logs for a specific date/time period —
be prepared to produce these within 24 hours of request
5. Session controls active
Prepare: evidence of 15-minute screen lock (GPO setting)
Show: inactivity timeout configured on workstations and RDP sessions
Assessor may observe a workstation being left idle —
confirm it locks within 15 minutes automatically
Notification obligation for DEFSTAN:
If any DEFSTAN-contract personnel leave during the assessment period:
The contracting authority must be notified
This is tracked in EV-D04 (CISO sign-off section: DEFSTAN authority notified)
Confirm the CISO is aware of any recent leavers who held clearance for
the DEFSTAN contract before the assessment commences
POA&M templates — most likely deficiencies for this control family
Use these templates immediately when a deficiency is identified — do not wait for the formal assessment cycle.
Template: Legacy authentication not fully blocked
POA&M item: PM-[YYYY]-[NNN]
Controls: IA.L1-3.5.2 · CE Requirement 5
Weakness: [X] successful legacy authentication events identified in
Entra ID sign-in logs for the period [date] to [date].
CA-003 (Block Legacy Authentication) is configured but
[specific legacy protocol / client type] is not covered
by the current policy scope.
Discovery source: [Monthly log review EV-F01 / MFA coverage report EV-D05 / assessment]
Risk during deficiency: High — legacy auth bypasses MFA, enabling credential-only access
to [specify affected systems]
Compensating controls: SIEM alert active for legacy auth success events;
IT Operations reviewing daily; affected accounts
have strong 20+ character passwords
Corrective action: Modify CA-003 to include the specific client app category
not currently covered; test in report-only mode for 5 days
before switching to block
Owner: IT Manager
Target completion: [14 days from identification]
CISO approval: required — High risk
Template: Account not disabled on departure day
POA&M item: PM-[YYYY]-[NNN]
Controls: AC.L1-3.1.1 · CE Requirement 3 · DEFSTAN Profile 0
Weakness: Account [UPN] for [name — departed on [date]] was not
disabled until [date] — a gap of [N] days.
The leaver de-provisioning checklist (EV-D04) was not initiated
until [N] days after the final working day.
Discovery source: [EV-D01 quarterly review / SIEM dormant account alert / other]
Risk during deficiency: [High if CUI access / Moderate if no CUI access]
Account was potentially accessible via retained credentials
for [N] days post-departure
Compensating controls: SIEM reviewed for account activity during the gap period
— result: [clean / anomalies found — see incident [ref]]
Corrective action: HR to initiate ITSM leaver request on the same day
resignation is accepted, not on final day;
IT Operations SLA: account disabled within 4 hours
of final day notification from HR
Owner: IT Manager + HR Manager
Target completion: [process change effective immediately;
training for HR and IT completed within 14 days]
CISO approval: required if CUI access was held
Template: Standard user with administrator group membership
POA&M item: PM-[YYYY]-[NNN]
Controls: AC.L1-3.1.2 · CE Requirement 2
Weakness: User account [firstname.lastname@domain] was found to be a
member of [Domain Admins / Local Administrators on [workstation]]
as of [discovery date]. This account is used for standard work
activities including email and web browsing — not exclusively
for administrative tasks.
Discovery source: [EV-D01 quarterly review / CE assessment / other]
Risk during deficiency: High — any malware executing under this account
would have administrative privileges on
the affected scope. Phishing or social
engineering targeting this user has
elevated potential impact.
Compensating controls: EDR monitoring on affected workstation/scope;
SIEM alert for privilege use from this account
Corrective action: (1) Remove firstname.lastname from privileged group immediately
(2) Create adm-firstname.lastname account with only
the required administrative scope
(3) Brief [user] on dual-account model
(4) Remove admin account from email and browser use
Owner: IT Manager
Target completion: immediate removal from group (within 24 hours);
admin account created within 5 business days
CISO approval: required
Cross-family evidence dependencies — this control family
The following evidence items from other families depend on or are directly affected by access control evidence quality:
AT-AU (Audit and Accountability): The audit log's evidentiary value depends on IA.L1-3.5.1 being properly implemented. If shared accounts exist, Event 4624 entries in the SIEM cannot be attributed to a specific individual — the audit trail is compromised. Verify EV-D03 has no shared accounts before relying on AT-AU evidence.
AT-PS (Personnel Security): EV-D03 (provisioning log) and EV-D04 (leaver checklist) are shared between the AC family (access control evidence) and the PS family (personnel security evidence). A gap in EV-D03 creates a finding against both families simultaneously.
AT-IA (Identification and Authentication): EV-D05 (MFA coverage report) appears in the evidence register for both this fundamental control page and the AT-IA advanced control page. Assessors examining the fundamental tier and the advanced tier will look at the same evidence items — ensure they are consistent and current before either assessment.
AT-CM (Configuration Management): The FGPP settings (minimum 16-character password) are part of the configuration baseline (EV-D19). If AT-CM evidence shows a baseline drift, the access control evidence chain for IA.L1-3.5.2 is weakened — an assessor who finds the FGPP settings differ from the documented baseline will question whether MFA and password policy settings are reliably enforced.
{scroll-content}
Page footer
All-staff visible — outside all SCM variant wrappers.
Where to go next
| If you are... | Go to... |
|---|---|
| An all-staff user who wants to understand your day-to-day obligations | 04 · User Guidance Hub → Passwords and MFA |
| An IT Operations engineer who needs the full JML workflow | FC-03 IT Staff Technical Procedures |
| An IT Operations engineer implementing the full AC control set | 03 · Advanced Controls → AT-AC · Access Control |
| An IT Operations engineer implementing the full IA control set | 03 · Advanced Controls → AT-IA · Identification and Authentication |
| A security team member preparing for a CMMC Level 1 assessment | AT-CA · Security Assessment → Section 8 (Assessor preparation) |
| A security team member preparing for a Cyber Essentials+ assessment | Contact the CISO — the Cyber Essentials self-assessment questionnaire is maintained by the CISO and reviewed annually |
| A security team member preparing for a DEFSTAN assessment | AT-CA → Section 8 + this page security layer (above) |
Version and review
| Version | Date | Change summary | Author | Approver |
|---|---|---|---|---|
| 1.0 | [DATE] | Initial publication | [NAME] | [CISO NAME] |
Page owner: IT Manager · Review: Annual · Questions: [helpdesk URL] or [ciso@organisation.com]