Access Requirements

You must determine and document specific access requirements for every IT and OT asset in your environment, including how users will connect remotely. This means creating formal policies that define who can access what, under which conditions, and through which methods—with particular attention to remote access protocols and authentication requirements.

Key takeaways:

• Document access requirements for every IT and OT asset before granting any access permissions
• Define specific remote access protocols, authentication methods, and connection requirements
• Create role-based access matrices that map job functions to required system access
• Implement technical controls that enforce your documented access requirements
• Maintain evidence of access requirement determinations for audit purposes

Access requirements form the foundation of identity and access management in cybersecurity maturity frameworks. The C2M2 v2.1 ACCESS-2.A requirement mandates that organizations establish formal criteria for accessing both Information Technology (IT) and Operational Technology (OT) assets, with explicit provisions for remote connectivity.

Most organizations fail this requirement by maintaining informal, undocumented access practices. Teams grant permissions based on verbal requests or replicate existing user profiles without analyzing actual business needs. This approach creates excessive privileges, orphaned accounts, and audit findings.

The requirement applies to energy sector organizations and critical infrastructure operators implementing C2M2. However, the principle extends to any organization managing third-party access, vendor connections, or remote workforce scenarios. Your access requirements must address both human users and service accounts, covering interactive logins and programmatic interfaces.

Regulatory text

The C2M2 v2.1 ACCESS-2.A requirement states: "Access requirements, including those for remote access, are determined for IT and OT assets."

This mandate requires organizations to establish formal criteria before granting any access to technology assets. You cannot simply provision accounts on request—you must first define what access is needed, why it's needed, and under what conditions it should be granted. The requirement specifically calls out remote access because it introduces additional risk factors that demand stricter controls.

Who This Applies To

This requirement targets:

• Energy sector organizations implementing C2M2
• Critical infrastructure operators in electricity, oil, and natural gas subsectors
• Any organization managing OT environments alongside traditional IT systems
• Companies with remote workforce or third-party access requirements

While framed for energy sector maturity, the principle applies universally. Financial services firms managing vendor connections, healthcare organizations with remote clinicians, and technology companies with distributed teams all need documented access requirements.

What You Actually Need to Do

Step 1: Inventory Your Assets

Create a comprehensive inventory of IT and OT assets requiring access control:

• Servers, workstations, and network devices
• Applications and databases
• OT systems including SCADA, DCS, and PLCs
• Cloud services and SaaS applications
• Development and test environments
• Administrative interfaces and management consoles

Document each asset's criticality, data sensitivity, and operational impact. This inventory becomes your baseline for access requirement decisions.

Step 2: Define Access Requirement Categories

Establish standard access requirement templates for different scenarios:

Local Access Requirements:

• Physical console access
• Local administrator privileges
• Service account permissions
• Maintenance access windows

Remote Access Requirements:

• VPN connectivity protocols
• Multi-factor authentication methods
• Session recording requirements
• Geographic restrictions
• Time-of-day limitations
• Device trust requirements

Third-Party Access Requirements:

• Vendor support connections
• Consultant project access
• Auditor read-only permissions
• Integration service accounts

Step 3: Create Role-Based Access Matrices

Develop formal matrices mapping job functions to required access:

Role	Systems Required	Access Level	Remote Access	Special Conditions
Control Room Operator	SCADA, HMI	Read/Execute	No	On-site only
System Administrator	All IT systems	Full Admin	Yes - VPN+MFA	24/7 on-call
Vendor Support	Specific application	Limited Admin	Yes - Jump server	Time-boxed sessions
Compliance Auditor	All systems	Read-only	Yes - Screen share	Supervised access

Step 4: Document Technical Requirements

Specify technical controls for each access scenario:

• Authentication methods (passwords, certificates, biometrics)
• Session timeout values
• Concurrent session limits
• Encryption requirements
• Logging and monitoring specifications
• Privilege escalation procedures

Step 5: Establish the Approval Process

Create formal workflows for access requirement determination:

1. Business owner identifies access need
2. Security team reviews risk implications
3. IT/OT team confirms technical feasibility
4. Management approves based on business justification
5. Requirements documented in access control system

Required Evidence and Artifacts

Maintain these documents for audit evidence:

• Access Requirements Policy: Formal document outlining your approach
• Asset Inventory: Current list of all IT/OT assets with access controls
• Access Requirement Matrices: Role-based mappings for each system
• Remote Access Standards: Technical specifications for remote connectivity
• Approval Records: Documented decisions for each access requirement
• Exception Log: Justified deviations from standard requirements

Common Exam Questions and Audit Findings

Auditors typically focus on these areas:

"Show me how you determine access requirements for a new OT asset." Have a documented process walkthrough ready, including stakeholder involvement, risk assessment, and technical control selection.

"How do you differentiate between IT and OT access requirements?" Demonstrate understanding of OT-specific concerns: availability over confidentiality, change control windows, vendor dependencies, and safety implications.

"What happens when someone needs emergency access?" Document your break-glass procedures while showing they still follow abbreviated requirement determination.

"How do you handle contractor remote access?" Show enhanced requirements for third parties: time-boxed access, enhanced monitoring, jump servers, and session recording.

Common audit findings include:

• No documented access requirements (just ad-hoc provisioning)
• IT requirements applied to OT without modification
• Remote access lacking enhanced controls
• Requirements not updated when systems change
• Approved access exceeding documented requirements

Implementation Mistakes to Avoid

Mistake 1: One-Size-Fits-All Requirements Creating generic access requirements for all systems ignores risk variations. OT systems need different considerations than email servers. Tailor requirements to asset criticality.

Mistake 2: Focusing Only on User Access Service accounts, API keys, and system integrations need requirements too. These non-human identities often have broader permissions and weaker governance.

Mistake 3: Documenting Without Enforcement Requirements mean nothing without technical controls. Implement network segmentation, authentication systems, and monitoring to enforce your documented requirements.

Mistake 4: Ignoring Third-Party Access Vendors, contractors, and partners often receive less scrutiny than employees. Define specific requirements for external access, including enhanced monitoring and restricted permissions.

Practical 30/60/90-Day Execution Plan

Immediate Actions (First 30 Days):

• Inventory critical IT and OT assets requiring immediate attention
• Document current access patterns to establish baseline
• Identify systems with remote access capabilities
• Draft initial access requirements policy
• Begin stakeholder engagement for requirement gathering

Near-Term Goals (Days 31-60):

• Complete comprehensive asset inventory
• Develop role-based access matrices for critical systems
• Define remote access technical standards
• Create approval workflow and forms
• pilot new requirements on select systems

Ongoing Maturation (Days 61-90):

• Roll out requirements to all IT/OT assets
• Implement technical controls to enforce requirements
• Train staff on new approval processes
• Conduct initial compliance assessment
• Refine requirements based on operational feedback

Connection to Other Requirements

Access requirements support multiple compliance frameworks beyond C2M2:

• NERC CIP requires documented access control for critical cyber assets
• NIST Cybersecurity Framework calls for access control policies (PR.AC-1)
• ISO 27001 mandates access control requirements (A.9.1.1)
• IEC 62443 specifies access requirements for industrial systems

Organizations implementing comprehensive access governance often leverage platforms like Daydream to track requirements across frameworks, ensuring consistent implementation while avoiding duplicative efforts.

Frequently Asked Questions

How detailed should access requirements be for every single asset?

Group similar assets with identical risk profiles to avoid documentation overload. Create detailed requirements for asset categories (like "HMI workstations" or "domain controllers") rather than documenting each device individually. Critical unique assets warrant individual documentation.

What's the difference between access requirements and access controls?

Access requirements define what access should be granted and under what conditions. Access controls are the technical mechanisms that enforce those requirements. Requirements come first and drive control selection.

How do we handle legacy OT systems that can't support modern authentication?

Document compensating controls in your access requirements. If a legacy PLC can't support multi-factor authentication, require network isolation, jump server access, and enhanced monitoring as alternative controls. The requirement determination process should identify these limitations.

Should vendor default accounts be covered in access requirements?

Yes. Document requirements for managing default accounts including disabling when possible, changing default credentials, monitoring usage, and restricting permissions. Many OT compromises exploit unchanged vendor defaults.

How often should we review and update access requirements?

Review requirements annually at minimum, plus whenever systems undergo major changes, new vulnerabilities emerge, or after security incidents. Critical infrastructure systems may warrant quarterly reviews.

Can we use the same access requirements for IT and OT systems?

While some principles overlap, OT systems need specialized requirements addressing availability priorities, maintenance windows, vendor dependencies, and safety systems. Start with IT requirements as a baseline but customize for OT operational needs.