Access Requirements

To meet the C2M2 “Access Requirements” requirement, you must define and document access rules for both IT and OT assets, including remote access, so access is granted based on business need and security risk. Operationalize it by scoping assets, setting role- and system-specific requirements, standardizing approvals and provisioning, and retaining evidence that access decisions are authorized and periodically revalidated. ¹

Key takeaways:

• Define access requirements per asset type (IT and OT) and per access path (local, remote, privileged), not as a single generic policy. ¹
• Standardize how access is requested, approved, provisioned, reviewed, and revoked, and keep the records that prove each step happened. ¹
• Treat remote access to OT as a special case with explicit conditions (methods, approvals, and constraints) documented upfront. ¹

“Access requirements” sounds basic, but audits and internal control testing often fail on the same point: the organization cannot show that access rules were deliberately determined for the actual assets in scope, especially for operational technology (OT) and remote access pathways. C2M2 frames this as a maturity baseline: you determine access requirements for IT and OT assets, including remote access. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this requirement as a design-and-evidence exercise. Design means you decide, in writing, what “allowed access” looks like for each meaningful asset class (for example: corporate IT apps, identity systems, engineering workstations, SCADA/HMI, historians, remote support jump hosts), including who can access, from where, under what authentication, and with what approvals. Evidence means you can produce request/approval/provisioning/review/revocation records that match those requirements. ¹

This page gives you requirement-level implementation guidance you can hand to IAM, OT, and infrastructure owners to execute quickly, plus the artifacts you should demand to make the control defensible during assessments aligned to DOE’s C2M2 program. ²

Regulatory text

C2M2 v2.1 ACCESS-2.A (MIL1) excerpt: “Access requirements, including those for remote access, are determined for IT and OT assets.” ¹

What the operator must do:

• Determine (decide and document) access requirements for in-scope IT assets and in-scope OT assets. ¹
• Include remote access in those requirements, not as an afterthought or a separate, informal practice. ¹
• Make the requirements concrete enough that teams can implement them consistently and you can test them using objective evidence (requests, approvals, and access reviews). ¹

Plain-English interpretation

You need written, approved access rules for the systems that matter, including OT, and you need to be able to prove you followed those rules each time you granted, changed, reviewed, or removed access. If a key system has no defined access requirements, or remote access is “handled by the network team” with no documented requirements, you will struggle to justify why access exists and whether it is appropriate. ¹

Who it applies to

Entity scope: Energy sector organizations and other critical infrastructure operators that adopt C2M2 for a defined scope (business unit, environment, or function). ¹

Operational context where this becomes urgent:

• Hybrid IT/OT environments (enterprise identity tied to OT access).
• Remote maintenance or support (third-party remote access, VPN, jump hosts, remote desktop tools).
• Privileged access to engineering workstations, HMIs, historians, and management interfaces.
• M&A, carve-outs, or rapid onboarding of contractors where “temporary” access becomes permanent.

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

Step 1: Define your in-scope asset population (IT and OT)

1. Identify the systems where unauthorized access would create operational, safety, reliability, or material business risk.
2. Separate them into practical buckets you can manage (examples below).
3. Assign an asset owner for each bucket who can approve requirements and exceptions.

Practical buckets that work in real programs:

• Enterprise identity directory / SSO / MFA systems (IT)
• Core business apps and data platforms (IT)
• Privileged access tooling (IT)
• OT operator interfaces (HMI/SCADA consoles) (OT)
• Engineering workstations and configuration tools (OT)
• OT historians / reporting (OT)
• Remote access entry points (VPN, ZTNA, jump servers, remote support platforms) (IT/OT boundary)

Step 2: Create an “Access Requirements Standard” and a per-asset appendix

Write a short standard (a few pages) that sets the minimum required decisions for access. Then maintain an appendix or system sheets per asset bucket.

Your standard should require each system/asset class to declare:

• Roles permitted (job roles, not named people) and least-privilege intent
• Authentication requirements (for example, MFA required for remote access; stronger requirements for privileged actions)
• Authorization model (RBAC groups, entitlements, privileged roles)
• Remote access conditions (allowed methods, required routing such as jump host, session controls, and logging expectations)
• Approval rules (who must approve, including asset owner and manager; when security approval is required)
• Provisioning method (ticket + IAM workflow; break-glass path)
• Review cadence trigger (event-based triggers like role change, termination, contractor end date; and periodic revalidation expectation)
• Revocation triggers (termination, contract end, role change, inactivity, exception expiry)

This directly maps to the C2M2 expectation that access requirements are “determined” rather than implied. ¹

Step 3: Treat remote access as a distinct access path with explicit requirements

For remote access, define requirements that are explicit enough to test. For each remote pathway, document:

• Who is allowed to initiate remote sessions (employees, contractors, third party support)
• Whether remote access is allowed to OT networks directly or only through controlled intermediaries (for example, jump hosts)
• Required approvals for enabling remote access (standing access vs time-bound)
• Required session constraints (time windows, command restrictions where feasible, recording where feasible)
• Required evidence (tickets, approvals, logs, exception records)

Remote access is called out in the regulatory text, so “we have VPN” is not a requirement; it’s a tool. The requirement is the documented rule set for when and how remote access is granted. ¹

Step 4: Standardize the access lifecycle workflow (request → approve → provision → review → revoke)

Implement a workflow that produces consistent artifacts:

1. Request: Require a ticket or workflow submission that identifies system, role/entitlement requested, business justification, start/end date (especially for contractors), and whether remote access is needed.
2. Approval: Require approval by the requestor’s manager and the asset owner; add security approval for privileged roles and for remote access into sensitive environments.
3. Provisioning: Provision through IAM groups or managed entitlements where possible; for OT where manual provisioning is common, require a provisioning checklist and screenshot/log extract as completion evidence.
4. Review: Run periodic revalidation and event-driven reviews (terminations, transfers, contractor offboarding). Record results and remediation actions.
5. Revocation: Ensure timely removal and retain proof of deprovisioning.

This is the fastest way to make “determined access requirements” real: requirements plus an operating process that enforces them and generates evidence. ¹

Step 5: Define and govern exceptions

You will have exceptions in OT. Make them controlled:

• Document the exception reason, compensating controls, approving authority, and expiry criteria.
• Require re-approval if the exception expires or conditions change.
• Track exceptions centrally so you can answer audit questions without hunting.

Step 6: Prove it with a simple test plan

Build a lightweight test approach aligned to C2M2:

• Sample access grants for key systems (including at least one remote access case and one OT case).
• For each sample, show request, approval, provisioning evidence, and whether it was included in the latest review.
• Sample terminations/transfers and show revocation evidence.

If you use Daydream to run third-party risk and vendor due diligence, mirror this same evidence discipline for third-party remote access. Require third parties to provide their access request and approval trail, named operators, and session logging expectations as part of onboarding and renewal.

Required evidence and artifacts to retain

Retain evidence that ties back to the two recommended practices in the source data: define requirements and retain records of access decisions and revalidation. ¹

Policy/standards artifacts

• Access Requirements Standard (IT + OT scope statement)
• Remote Access Requirements (may be a section in the standard)
• System/asset access requirement sheets ¹
• Exception register (with approvals and expiry)

Operational records

• Access requests (tickets/workflows)
• Approval records (manager, asset owner, security where required)
• Provisioning completion evidence (IAM logs, screenshots, admin logs, change records)
• Access review outputs (attestations, findings, remediation tickets)
• Revocation records (termination offboarding, contractor end dates, group removals)

Common exam/audit questions and hangups

Expect assessors to ask questions that test whether requirements exist per asset and whether operation matches the paper.

Common questions:

• “Show me the access requirements for this OT asset and how remote access is handled.” ¹
• “Who is the designated approver (asset owner) for access to this system?”
• “Show evidence for three access grants: request, approval, provisioning.” ¹
• “How do you ensure access is removed after role change or contract end?”
• “Where are exceptions documented, and how do you ensure they expire?”
• “How do you revalidate access periodically, and where are the results recorded?” ¹

Hangups that stall reviews:

• OT access managed locally with no consistent request/approval trail
• Shared accounts with no documented requirement or compensating controls
• Remote access enabled permanently “for convenience,” with no owner approval record
• Requirements exist but are generic and do not address remote access pathways

Frequent implementation mistakes (and how to avoid them)

1. Mistake: One generic access policy for everything.
   Fix: Keep a short enterprise standard, but require per-system access requirement sheets for critical IT and OT assets. ¹

2. Mistake: Remote access treated as a network configuration, not an access requirement.
   Fix: Document remote access eligibility, approvals, and constraints per environment, then test it with samples. ¹

3. Mistake: Approvals happen in chat/email with no durable record.
   Fix: Route through a ticketing or IAM workflow that retains approvals and timestamps. ¹

4. Mistake: OT teams cannot produce provisioning/revocation proof.
   Fix: Use a simple OT access checklist and require attaching evidence (screenshots/log snippets) to the ticket.

5. Mistake: Exceptions never expire.
   Fix: Add expiry to every exception and require re-approval to renew.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement outcomes. The practical risk is still clear: if you cannot show that access requirements were determined and followed, inappropriate access can persist and access decisions become hard to justify during internal control testing, audits, customer due diligence, or regulator review. ¹

Practical execution plan (30/60/90-day)

First 30 days

• Confirm scope: list critical IT and OT assets plus all remote access entry points in scope. ¹
• Assign asset owners and approval authorities for each asset bucket.
• Draft the Access Requirements Standard with a dedicated remote access section. ¹
• Stand up a minimum viable evidence path: a ticket type/workflow that captures request + approvals + provisioning evidence attachment. ¹

By 60 days

• Publish per-asset access requirement sheets for the highest-risk systems (prioritize OT and remote access paths). ¹
• Implement an exception register with expiry and compensating control fields.
• Run a small access review for one IT system and one OT system; capture results and remediation tickets. ¹
• If third parties have remote access, require documented access requirements and approvals as part of third-party onboarding and renewals.

By 90 days

• Expand access requirement sheets across remaining in-scope assets. ¹
• Operationalize event-driven revocation triggers with HR/contractor offboarding inputs.
• Run a second access review cycle and verify closure of findings. ¹
• Package an assessment-ready evidence binder: standards, asset sheets, sample tickets, review outputs, and exception register exports. ¹

Frequently Asked Questions

Do we need separate access requirements for IT and OT?

You need access requirements that explicitly cover both IT and OT assets, and OT usually needs additional specificity (local admin practices, shared engineering tools, maintenance access). The requirement is satisfied when access requirements are determined for the assets in scope, not when a single generic policy exists. ¹

What counts as “remote access” for this requirement?

Any access path where a user connects from outside the normal trusted environment or through remote connectivity methods (VPN, remote desktop tools, third-party support connections). The key is to document the conditions, approvals, and constraints for that access path. ¹

Our OT systems can’t integrate with IAM. Can we still comply?

Yes, but you must document the OT access requirements and enforce them through operational process controls (ticketed approvals, provisioning checklists, and revocation evidence). Auditors will still expect a durable record that access was authorized and revalidated. ¹

How do we handle shared accounts that exist in OT?

Treat them as exceptions: document why they exist, who can use them, how credentials are protected, and what compensating controls apply. Put an expiry on the exception and track it in the exception register with re-approval. ¹

What evidence is the fastest to produce during an assessment?

A small set of access tickets that show request, approval, provisioning evidence, and inclusion in an access review is usually the fastest. Pair that with the written access requirements for the same systems and your exception register. ¹

Where does Daydream fit if the main issue is access control?

Daydream helps when remote access or privileged access involves third parties, which is common in OT support. You can standardize third-party access requirements, collect approvals and evidence, and keep a clean audit trail aligned to your internal access requirement sheets. ¹

Footnotes

1. Cybersecurity Capability Maturity Model v2.1

2. DOE C2M2 program