Identity Management

To meet the C2M2 Identity Management requirement, you must establish a controlled lifecycle for every identity that can access organizational assets: request, approve, provision, change, review, and revoke. Scope includes employees, contractors, third parties, service accounts, and (where applicable) OT/ICS identities, with evidence that access decisions were authorized and periodically revalidated. ¹

Key takeaways:

• You need an identity inventory and a repeatable joiner/mover/leaver process that covers human and non-human accounts. ¹
• Auditors will look for proof: access requests, approvals, provisioning logs, periodic review results, and termination revocation evidence. ¹
• The fastest path to operationalize is to standardize approvals, centralize identity sources, and calendar access reviews tied to system criticality. ¹

“Identity Management” in C2M2 is a requirement-level expectation: identities must be provisioned and managed for anyone or anything that needs access to organizational assets. ¹ For a Compliance Officer, CCO, or GRC lead, the practical question is not what IAM is in theory, but what minimum operating model proves you control access decisions across IT and OT, and can show that control under audit.

This requirement becomes urgent where you have multiple identity stores (HR, Active Directory, cloud IAM, OT local accounts), frequent contractor onboarding, or service accounts created informally for integrations and automation. Those are the conditions that create “orphaned” access and accounts nobody owns, which becomes a predictable audit finding because you cannot justify who approved access, whether it is still needed, or whether it was removed on exit.

C2M2 is a maturity model used by energy sector and critical infrastructure operators to assess cybersecurity capabilities within a defined scope. ¹ Treat this page as an implementation checklist you can turn into a control narrative, test plan, and evidence package.

Regulatory text

Requirement (C2M2 ACCESS-1.A, MIL1): “Identities are provisioned and managed for personnel and other entities who require access to organizational assets.” ¹

Operator interpretation (what you must do):

• Maintain controlled creation and management of identities for personnel (employees, temps) and other entities (contractors, third parties, service accounts, shared technical identities where unavoidable, and system-to-system identities). ¹
• Make identity actions intentional and traceable: access is requested, approved, provisioned, changed, and removed through a defined process, not ad hoc tickets with missing approvers. ¹
• Retain evidence that identity decisions were authorized and revalidated on a cadence you define. ¹

Who it applies to

Entity scope

• Energy sector organizations and critical infrastructure operators using C2M2 to assess a business unit, function, or OT environment. ¹

Operational scope (what systems and identities)

• IT assets: directory services, email, endpoints, servers, SaaS, cloud consoles, privileged access platforms.
• OT/ICS assets in scope: HMI/SCADA access, engineering workstations, OT jump hosts, remote access gateways, plant historians, vendor-maintained appliances.
• Identity types:
  • Human users (employees, interns, temps).
  • Contractor and third-party user identities (including break-glass or emergency accounts if used).
  • Non-human identities (service accounts, API keys mapped to service principals, automation/runbook accounts). ¹

Plain-English requirement

You must be able to answer, for any account that can access an asset: Who owns it, why does it exist, who approved it, what access it has, and when it was last reviewed? If you cannot answer those questions consistently, you have not operationalized this requirement. ¹

What you actually need to do (step-by-step)

1) Define identity governance rules (minimum viable)

Create a short “Identity Management Standard” that states:

• Identity sources of truth (HR system for employees; contractor management system or procurement onboarding for third parties; CMDB/app owner for service accounts).
• Approval criteria (who can approve what, and under which conditions). ¹
• Provisioning steps for common access patterns (standard roles/groups).
• Review cadence (set by system criticality and role sensitivity).
• Revocation triggers (termination, contract end, role change, inactivity, policy breach). ¹

Deliverable: a 2–5 page standard plus one-page RACI.

2) Build an identity inventory (humans + non-humans)

You need a working list that ties:

• Identity → person/service owner
• Identity → systems it accesses
• Identity → role/group membership
• Identity → approval record location
• Identity → status (active/disabled) and last review date

Practical tip: start with your authoritative directory and cloud IAM, then reconcile OT local accounts separately if needed.

3) Implement joiner/mover/leaver (JML) workflows

Joiner

• Request comes from manager/sponsor (or HR event).
• Access package maps to job function and least privilege.
• Provision via ticketing/IAM workflow with required approvals.

Mover

• Role change triggers group/role reassessment.
• Remove access that no longer matches the role.
• Re-approve elevated access.

Leaver

• HR termination or contract end triggers disablement and revocation.
• For OT, include removal from jump hosts, VPNs, remote support tools, and any local device accounts.

4) Control third-party identities explicitly

Third-party access is where identity management breaks first.

• Require a business sponsor for each third-party identity.
• Use named accounts where possible; document exceptions.
• Enforce time-bound access for contractors aligned to engagement end dates.
• Track third-party identities in the same inventory and review cycle as employees. ¹

5) Control service accounts and automation identities

Service accounts often have persistent privileges and weak ownership. Minimum controls:

• Assign an account owner (an application owner, not “IT” generically).
• Document purpose, systems used, and permissions granted.
• Define credential management approach (password vaulting, key rotation process, or managed identity where supported).
• Review service account privileges and continued need on the same cadence as privileged access.

6) Run periodic access reviews and remediate

Pick review targets that auditors expect first:

• Privileged roles (domain admins, cloud admins).
• Remote access users (VPN, OT jump servers).
• Third-party users.
• Service accounts with broad access.

A workable review format:

• Reviewer: system owner (not the same person who requested access).
• Output: approve/keep, modify, or revoke.
• Follow-up: ticket links proving changes were executed. ¹

7) Define exceptions and make them testable

Common exceptions: shared accounts in OT due to legacy limitations, vendor appliance accounts, emergency access. Require:

• Written justification
• Compensating controls (monitoring, jump host controls, session recording where available)
• Expiration date and re-approval
• Named executive/system owner acceptance

8) Document the control narrative and testing approach

Write a control description that maps to the requirement text and states:

• Systems in scope
• Workflow steps
• Approval roles
• Review cadence
• Evidence produced and retained ¹

This becomes your audit script.

Required evidence and artifacts to retain

Retain artifacts that prove identities are provisioned and managed, not just described. ¹

Policy/standards

• Identity Management Standard (approval criteria, provisioning steps, review cadence, revocation triggers). ¹
• RACI for identity approvals and reviews.

Operational records

• Access requests and approvals (tickets/workflow records). ¹
• Provisioning logs (IAM tool logs, directory audit logs, change tickets).
• Termination/contract-end revocation evidence (disablement records, deprovisioning tickets).
• Periodic access review results and remediation tickets. ¹
• Exception register with approvals and expirations. ¹

Inventories

• Identity inventory (including service accounts and third-party identities).
• System list in scope and system owners.

Common exam/audit questions and hangups

Auditors tend to test identity management by sampling accounts and walking them through lifecycle evidence. Expect:

• “Show me how a contractor gets access, who approves it, and how you remove it at offboarding.” ¹
• “List all service accounts, their owners, and why they need their permissions.”
• “Provide the last access review for privileged access and evidence of remediation.”
• “How do you know you captured all identity stores, including OT local accounts?”
• “What is your process for exceptions like shared accounts?”

Hangups that cause findings:

• Approvals exist but are from the wrong role (peer approval, generic IT approval).
• Reviews are completed but remediation is not tracked to closure.
• Service accounts have no owner or no request/approval trail.

Frequent implementation mistakes (and how to avoid them)

1. Treating IAM tooling as the control. Tools help, but the control is the governed process plus evidence. Write the workflow, then configure tools to enforce it. ¹

2. Ignoring non-human identities. Put service accounts and API identities in scope on day one. Give them owners and review them.

3. Third-party access managed outside governance. Fold contractor onboarding into the same identity lifecycle with the same approvals and offboarding triggers.

4. No “source of truth” for employment status. Tie leaver actions to HR/contract end events, not manual emails.

5. Reviews without risk focus. Start with privileged, remote, third-party, and OT access paths. Expand coverage after the first clean cycle.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, weak identity management shows up as: persistent inappropriate access, inability to justify access decisions during audits and customer diligence, and longer containment times during incidents because you cannot quickly map identities to owners and entitlements. ¹

Practical 30/60/90-day execution plan

The plan below is structured for speed without relying on unsourced timing claims. Adjust sequencing to your change windows and OT constraints.

First 30 days (stabilize and define)

• Confirm scope: business unit, IT systems, OT zones included in the C2M2 assessment. ¹
• Publish the Identity Management Standard with approvals, provisioning steps, review cadence, revocation triggers. ¹
• Build an initial identity inventory from your primary directory and cloud IAM, then list “known other stores” (OT locals, vendor appliances).
• Define approval matrix: standard access vs privileged vs third-party vs service accounts.
• Stand up an exception register.

Days 31–60 (operate the workflow and produce evidence)

• Implement or tighten JML workflows in ticketing/IAM.
• Run a first access review on privileged and remote access, plus a targeted review of third-party identities.
• Remediate obvious issues: orphan accounts, missing owners, stale contractor access.
• Document the control narrative and evidence map (what evidence, where it lives, who produces it). ¹

Days 61–90 (expand coverage and harden)

• Expand periodic reviews to remaining high-impact systems and OT access points in scope.
• Formalize service account governance: ownership, purpose, approvals, and review process.
• Validate offboarding by sampling recent leavers and confirming deprovisioning across systems.
• Prepare an audit-ready packet: policy, RACI, samples of requests/approvals, review outputs, remediation tickets, exception logs. ¹

Where Daydream fits (earned mention)

If you are running identity evidence collection across multiple systems and third parties, Daydream can centralize request/approval records, access review outputs, and exception tracking into a single audit package. Use it to standardize evidence capture and reduce the scramble when an assessor asks for “proof, not screenshots.”

Frequently Asked Questions

Does this requirement include contractors and other third parties, or only employees?

It explicitly covers “personnel and other entities,” so contractors, third parties, and non-human identities are in scope if they access organizational assets. Treat third-party onboarding and offboarding as part of the same identity lifecycle. ¹

Are service accounts really “identities” under this requirement?

Yes. Any account or principal that can authenticate and access assets qualifies as an identity you must provision and manage. Assign owners, document purpose, and include them in reviews. ¹

What’s the minimum evidence an auditor will accept for identity provisioning?

Keep the access request, the approval showing an authorized approver, and a record that provisioning occurred (ticket completion notes or system audit logs). Pair that with periodic review results and revocation evidence for leavers. ¹

How do we handle OT systems that only support shared accounts?

Record the exception with a business/system owner sign-off, set an expiration date, and document compensating controls such as restricted jump-host access and enhanced monitoring. Track it in your exception register and re-approve it on a defined cadence. ¹

What should we review first if we can’t review everything?

Start with privileged access, remote access paths, third-party identities, and high-impact systems. Those areas drive the most audit scrutiny because they concentrate risk and typically have the weakest ownership clarity. ¹

We have multiple directories and SaaS apps. Do we need a single IAM tool to comply?

The requirement is control of provisioning and management, not a specific tool mandate. You can meet it with consistent workflows, an inventory that spans identity stores, and retained evidence of approvals and periodic revalidation. ¹

What you actually need to do

Use the cited implementation guidance when translating the requirement into day-to-day operating steps. ²

Footnotes

1. Cybersecurity Capability Maturity Model v2.1

2. DOE C2M2 program