Identity Management

The C2M2 Identity Management requirement (ACCESS-1.A) mandates that organizations establish comprehensive processes for managing digital identities across their entire ecosystem. This foundational access control requirement applies to energy sector organizations and critical infrastructure operators who must secure both Information Technology (IT) and Operational Technology (OT) environments.

Identity management extends beyond simple user account creation. Modern implementations must address the full identity lifecycle, from initial provisioning through ongoing management to eventual deprovisioning. The requirement encompasses all entity types that interact with organizational assets — not just employees, but also contractors, third-party service providers, automated systems, and machine identities.

For compliance officers operationalizing this requirement, success hinges on establishing repeatable, documented processes that can withstand regulatory scrutiny while enabling business operations. The following guidance provides a roadmap for building an audit-ready identity management program that meets C2M2 expectations.

Regulatory text

The C2M2 v2.1 ACCESS-1.A requirement states: "Identities are provisioned and managed for personnel and other entities who require access to organizational assets."

This concise regulatory language encompasses a broad operational mandate. Organizations must implement systematic processes to create, modify, and remove digital identities for any entity — human or non-human — that requires access to organizational resources. The requirement applies equally to traditional IT systems and operational technology environments, requiring a unified approach to identity management across technology domains.

Plain-English Interpretation

Your organization needs a formal process to manage digital identities throughout their entire lifecycle. This means:

1. Creating identities when new users or systems need access
2. Maintaining identities as roles and responsibilities change
3. Removing identities when access is no longer required
4. Documenting all identity management activities for audit purposes

The scope explicitly includes "other entities" beyond personnel, capturing service accounts, API keys, machine identities, and automated systems that access organizational resources.

Who This Applies To

Primary entities covered:

• Energy sector organizations implementing C2M2
• Critical infrastructure operators in the energy sector
• Organizations pursuing C2M2 certification at any maturity level

Operational contexts requiring compliance:

• IT environments (corporate networks, cloud platforms, applications)
• OT environments (SCADA systems, industrial control systems, field devices)
• Hybrid IT/OT environments with interconnected systems
• Third-party access scenarios where external entities require system access

Step-by-Step Implementation

Phase 1: Discovery and Documentation (Days 1-30)

1. Inventory all identity types

   • Human users (employees, contractors, consultants)
   • Service accounts (application-to-application)
   • Machine identities (servers, IoT devices, certificates)
   • Privileged accounts (administrative, emergency access)

2. Map current identity sources

   • Active Directory/LDAP directories
   • Cloud identity providers (Azure AD, Okta, AWS IAM)
   • Local system accounts
   • Application-specific user stores
   • OT system user databases

3. Document existing processes

   • Current provisioning workflows
   • Approval chains and authorization methods
   • Deprovisioning procedures
   • Identity verification methods

Phase 2: Process Development (Days 31-60)

4. Create identity lifecycle procedures

   • Provisioning SOP: Define standard request forms, approval workflows, and provisioning timelines
   • Modification SOP: Document role changes, department transfers, and access adjustments
   • Deprovisioning SOP: Establish termination workflows, access revocation timelines, and verification steps

5. Establish identity governance framework

   • Identity naming conventions
   • Role definitions and access templates
   • Segregation of duties matrix
   • Periodic access review schedules

6. Define evidence retention requirements

   • Access request forms and approvals
   • Provisioning/deprovisioning logs
   • Access review documentation
   • Exception records and justifications

Phase 3: Implementation and Validation (Days 61-90)

7. Deploy identity management tools

   • Configure centralized identity stores
   • Implement automated provisioning where feasible
   • Enable audit logging for all identity operations
   • Establish monitoring for orphaned or unused accounts

8. Train personnel

   • Identity management team on new procedures
   • Managers on approval responsibilities
   • IT/OT staff on technical implementation
   • Auditors on evidence locations

9. Conduct initial validation

   • Test provisioning workflows end-to-end
   • Verify deprovisioning effectiveness
   • Review audit trail completeness
   • Perform sample access reviews

Required Evidence and Artifacts

Maintain these documents for audit readiness:

Document Type	Description	Retention Period
Identity Management Policy	High-level governance document defining scope and responsibilities	Current version + 2 previous
Provisioning Procedures	Step-by-step workflows for creating identities	Current version + 1 previous
Access Request Forms	Completed forms with approvals for each identity	3 years minimum
Provisioning Logs	System logs showing identity creation activities	1 year minimum
Access Reviews	Periodic certification of active identities	2 review cycles
Deprovisioning Records	Evidence of identity removal with timestamps	3 years minimum
Exception Reports	Documentation of emergency access or policy deviations	3 years minimum

Common Exam Questions and Audit Focus Areas

Auditors typically probe these areas:

1. "Show me how you provision a new contractor identity"

   • Have documented procedures ready
   • Demonstrate approval workflows
   • Show sample completed requests

2. "How do you ensure terminated employees lose access?"

   • Present deprovisioning procedures
   • Show HR integration or triggers
   • Provide termination audit logs

3. "What about service accounts and non-human identities?"

   • Document service account inventory
   • Show ownership assignments
   • Demonstrate periodic reviews

4. "How do you handle emergency access situations?"

   • Present break-glass procedures
   • Show approval documentation
   • Demonstrate post-incident reviews

Common Implementation Mistakes

Mistake 1: Focusing only on employee accounts

• Reality: C2M2 explicitly requires managing "other entities"
• Fix: Include service accounts, API keys, and machine identities in scope

Mistake 2: Manual processes without audit trails

• Reality: Paper-based systems often lack timestamps and verification
• Fix: Implement electronic workflows with automatic logging

Mistake 3: Inconsistent deprovisioning

• Reality: Access often persists after separation
• Fix: Establish SLAs (24-hour termination, 48-hour transfers)

Mistake 4: No regular access reviews

• Reality: Access accumulates over time without governance
• Fix: Quarterly reviews for privileged access, annual for standard users

Mistake 5: Separate IT and OT identity systems

• Reality: C2M2 requires unified approach across domains
• Fix: Implement federated identity or documented correlation processes

Risk and Enforcement Context

While C2M2 is a capability maturity model rather than a regulation with direct enforcement, implementation gaps create several risk exposures:

Operational risks:

• Unauthorized access due to orphaned accounts
• Insider threats from excessive permissions
• Audit findings requiring costly remediation
• Failed C2M2 assessments impacting business opportunities

Strategic risks:

• Inability to demonstrate maturity for federal contracts
• Exclusion from sector-specific programs requiring C2M2
• Reputational damage from access-related incidents

30/60/90-Day Implementation Timeline

Immediate Actions (Days 1-30)

• Inventory all identity types and sources
• Document current state processes
• Identify critical gaps requiring immediate attention
• Assign identity management program owner
• Begin collecting existing evidence artifacts

Near-term Goals (Days 31-60)

• Draft identity management policy and procedures
• Design standard workflows and forms
• Select and configure identity management tools
• Establish evidence retention structure
• Conduct initial staff training

Ongoing Operations (Days 61-90+)

• Execute first full access review cycle
• Validate all workflows with test scenarios
• Refine procedures based on lessons learned
• Prepare for initial C2M2 assessment
• Implement continuous improvement processes

Frequently Asked Questions

Do we need to manage identities for temporary vendors who only access our facilities, not our systems?

C2M2 ACCESS-1.A specifically addresses identities for accessing "organizational assets," which primarily means IT/OT systems and data. Physical access control is typically covered under separate physical security requirements. However, if temporary vendors receive any digital credentials (even WiFi access), those identities fall under this requirement.

How should we handle shared accounts that multiple operators use for OT systems?

While shared accounts are discouraged, legacy OT systems often require them. Document these as exceptions, implement compensating controls (such as access logs and shift records), and maintain a transition plan toward individual accounts. The key is showing you've identified and are managing the risk.

What's the difference between identity management and access management in C2M2 context?

Identity management (ACCESS-1.A) focuses on creating and maintaining the digital identity itself. Access management involves assigning specific permissions to that identity. Think of identity management as issuing a driver's license, while access management determines which vehicles you're authorized to drive.

How often must we review and recertify user access?

C2M2 ACCESS-1.A doesn't specify review frequency, but industry practice suggests quarterly reviews for privileged accounts and annual reviews for standard users. Document your chosen frequency in policy and consistently execute to that schedule.

Can we use different identity management systems for IT versus OT environments?

Yes, technical separation is often necessary for OT environments. However, you must document how identities correlate across systems and maintain consistent governance processes. Consider federation or identity mapping to maintain oversight across domains.

What evidence do auditors most commonly request for this requirement?

Auditors typically request: (1) A sample of recent provisioning requests with approvals, (2) Deprovisioning logs for terminated employees, (3) Current user lists from key systems, and (4) Documentation of your last access review cycle. Keep these readily accessible.