AC.L2-3.1.15 Privileged remote access requirements

What AC.L2-3.1.15 privileged remote access asks for in CMMC Level 2

AC.L2-3.1.15 asks you to decide, in writing, which privileged commands may be run remotely and which security-relevant information may be accessed remotely, and then to enforce those decisions in the system. An assessor will look for both halves: the authorization itself and the technical mechanisms that stop a remote session from doing anything beyond it. The requirement is the Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.1.15, and it sits in the Access Control family alongside the other remote access requirements. The risk is straightforward. An administrative session that starts outside the trusted location, whether from a home network, a vendor laptop or a jump host nobody reviewed, can change security settings, read audit records or disable controls with the same authority as a privileged user sitting in the data center. Privileged work is also hard to scope in practice because it often runs through convenience tools that were never reviewed for it: remote desktop utilities, hosted consoles, scripts pushed through management agents and ticketing integrations. Each one can quietly become a path for privileged commands that nobody listed. The requirement is worth 1 point under 32 CFR 170.24, and it is not on the exclusion list in 32 CFR 170.21, so it can be placed on a POA&M for Conditional Level 2 status if the score is at least 88 of 110. Do not treat that as the plan. The CMMC Assessment Guide advises avoiding remote execution of privileged commands where possible, and only where it is necessary, documenting which roles may do it and enforcing that documentation through security mechanisms. Confirm the current POA&M rules and closeout terms in the eCFR text before you rely on them, since the program schedule has changed recently.

Which systems, roles and third parties AC.L2-3.1.15 covers in your CUI environment

Before you can authorize anything under AC.L2-3.1.15, you must decide which systems, roles and third parties fall inside the boundary. Each decision below changes how many privileged commands and security-relevant information types you must list, approve and show enforced. Settle these choices in writing before you draft the authorization records.

Systems with remotely reachable privileged functions

Start with every system that stores, processes or transmits CUI and ask which of its privileged functions can be invoked over a remote session. Include hypervisors, domain controllers, firewalls, database servers and cloud management consoles, not only the servers that hold CUI. A system with no remote privileged path may fall out of this requirement's list, but you should document why that is true. Ask your administrators to confirm the answer for each system rather than relying on the architecture diagram.

Privileged roles that run remote commands

List each role that holds privileged rights and note whether it works remotely. Typical roles include system administrators, security staff, database administrators and network administrators. Each role adds its own set of commands, so a team with five distinct admin groups requires five separate command inventories. Confirm that role membership matches the accounts actually able to connect remotely, because drift between the two is a common assessment finding.

Vendor and managed service provider support

Decide how vendor engineers and managed service providers reach your systems for troubleshooting or patching. Remote support sessions are often the highest-risk path because the people using them sit outside your direct control. Identify which commands a vendor may run remotely, whether each one needs a named approver, and how sessions are recorded. Confirm the terms with the provider in writing, since their staff are not covered by your internal role definitions.

Security logs and configuration consoles

Decide whether security logs, audit settings, firewall rule sets and configuration consoles count as security-relevant information for remote access purposes. Most assessors expect these to be included because an attacker who reads or alters them can hide activity. Once you include them, you must authorize which roles may view or change them remotely and enforce that restriction. Document the decision and the reasoning so an assessor can follow it.

Management paths and jump hosts

Map every path a privileged session can take, including bastion or jump hosts, management networks and out-of-band consoles. A remote command that passes through an intermediary still counts, so the intermediary's own permissions belong in the scope. Reducing the number of such paths lowers the number of authorizations you must document, which also aligns with the guidance to limit remote privileged execution where possible.

Scope changes the documentation load

Every decision above feeds the same register: systems, roles, commands and information types. Adding a system, a vendor or a log source multiplies the entries you must approve and show enforced, while removing a remote path shrinks that list. Re-check the register whenever the boundary changes, and confirm with your assessor how they expect scope changes to be evidenced before the assessment begins.

How assessors test privileged remote access under AC.L2-3.1.15

This table compares the four SP 800-171A assessment objectives for AC.L2-3.1.15, showing how each is tested, what evidence assessors request and where organizations usually fall short. Read it as a checklist: a requirement is MET only when every applicable objective is satisfied with evidence in final form, not drafts.

Assessment objective	How the assessor tests it	Evidence requested	Common finding
Privileged commands authorized for remote use are identified	Interview administrators and security staff, then examine the documented list of privileged commands and the systems they apply to	Approved list of privileged commands and functions that may run remotely, with owner and approval date	List exists but omits commands used by cloud consoles, hypervisors or network devices
Security-relevant information authorized for remote access is identified	Examine the data classification and access documentation for security logs, configuration files and key material, then interview staff who use them	Documented inventory of security-relevant information approved for remote viewing, mapped to roles	Logs or security tool dashboards are reachable remotely with no documented authorization
Remote execution of privileged commands is authorized	Examine role permissions and remote access procedures, then test whether an unauthorized role can run a listed command remotely	Role-to-command permission matrix, signed authorization records and remote access procedures	Authorization is informal, such as an email from a manager, and not tied to a role
Remote access to security-relevant information is authorized	Review remote access configuration settings and test the access management mechanism with a non-authorized account	Configuration exports from the remote access gateway, access control lists and audit records of denied and granted sessions	Authorization exists on paper but enforcement settings allow broader access than documented

Implementing privileged remote access controls step by step

This sequence takes an organization from an inventory of privileged commands and security-relevant data to a tested, logged and enforced remote access policy for AC.L2-3.1.15. Each step closes with a document or configuration output that an assessor can examine.

Inventory privileged commands and security data by system
Start by listing every system in the CUI assessment scope and the privileged commands that administrators can run on each one, such as account management, firewall rule changes, logging configuration and security tool administration. Add the security-relevant information on each system, including audit logs, key material, security configuration files and access control lists. Assign an owner for each system and record the source of each entry, such as a configuration export or a command history review. The output is a system-by-system inventory that an assessor can trace back to the system security plan.
Decide which functions may run remotely
For each inventoried command and data set, decide whether it may be executed or read remotely or must stay local only. The aim is to avoid remote execution of privileged commands where possible, so default to local-only and approve remote use only where an operational need is documented. Record the reason for each approval and the conditions attached, such as a required remote access gateway or a time-bound session. Have the system owner and the security lead sign the resulting authorization matrix. The signed matrix is the first piece of evidence that the organization has identified the privileged commands and security-relevant information authorized for remote use.
Document the roles allowed to act remotely
Map each approved remote function to the specific roles permitted to perform it, and state which roles are excluded. Keep the role definitions consistent with the least privilege and transaction control decisions already recorded for the system. Store the role matrix in the system documentation under change control so that additions or removals leave a record. Confirm with the system owner that each listed role matches a real account group in the directory or identity platform. The result is a role matrix that ties each remote privilege to a named role, which assessors use to check the enforcement in the next step.
Enforce roles in gateway and system settings
Translate the role matrix into enforcement points: the remote access gateway or jump host, system permissions, sudo rules and role configuration on each system. For example, a sudo policy can limit which commands an administrator group may run through a remote session, and gateway policy can restrict which groups may open a session at all. Export the active configuration from each enforcement point and compare it line by line with the signed matrix. Record any gap and close it before testing. The output is a set of configuration exports, such as sudoers files, gateway policy exports and directory group memberships, that show the documented roles are the ones the systems enforce.
Enable logging for remote privileged sessions
Turn on session logging and audit records for every remote privileged session and for any remote access to security-relevant information. Confirm that the log captures the account, the source, the time, the command or data accessed and the outcome, and that the logs are forwarded to a location the administrators cannot silently alter. Check that the logging configuration is included in the baseline so that a later change would be visible. Ask your logging platform vendor to confirm which fields a given session recording or command logging feature captures, rather than assuming. The output is a logging configuration export and a sample of audit records from an approved remote session.
Test that unauthorized roles are blocked
Run a test in which an account from a role that is not authorized attempts a remote privileged command and an attempt to read restricted security data. Repeat the test with an authorized role to show the expected action succeeds, and record both results. Capture the denial message, the gateway or system log entry and the corresponding audit record. Retain the test plan, the account used, the timestamps and the results, and have a second person review them. Assessors examine this kind of test output alongside interviews with administrators and security staff, so keep the evidence in final form. The completed test record shows that the authorization is enforced and not only documented.

Evidence that passes AC.L2-3.1.15 and how to keep it current

Assessors test AC.L2-3.1.15 by checking that the organization decided which privileged commands and security-relevant information may be used remotely, wrote that decision down, and enforced it. The artifacts below connect those three steps, and each one needs an owner and a trigger for updates so it stays accurate between assessments.

Authorization matrix by role

This is the core document. It lists each privileged command and each category of security-relevant information, the roles allowed to use it remotely, and the approver who signed the decision. Assessors compare it with the enforcement settings to confirm they match. Keep it under change control, with a named owner (usually the system security officer) and a rule that any new privileged tool, role or remote path triggers a matrix review before the change goes live. Confirm the matrix explicitly states that most privileged commands are not authorized for remote use, if that is your decision.

Remote access procedure

The procedure explains how an administrator requests, performs and closes a remote privileged session, including the approved access path, required multifactor authentication, ticket or change reference and the escalation contact. Assessors use it to test whether staff know the process, so run interviews with administrators against the written text. Review it on a set schedule and after any change to the gateway, VPN or jump host, and record the reviewer and date on the document.

Enforcement configuration exports

Exports from the identity provider, privileged access tooling, firewall and gateway show how the matrix is enforced: role-to-command mappings, command restrictions, source address aliases and gateway policy. Capture them as dated files stored with the matrix, and compare them against the matrix after each configuration change. A common gap is a permission granted in one tool but not blocked in another, so check every path that reaches the protected systems. Ask your assessor which export format they will accept before you rely on one.

Audit records of privileged sessions

Logs from the remote access gateway and privileged access tool should record who connected, from which source, which privileged commands ran and when the session ended. These records show the requirement operating in practice, not only on paper. Confirm that logs are forwarded to a central store and retained under your audit policy, and that someone reviews remote privileged activity on a defined cadence. Test a sample of entries against the authorization matrix to find roles that ran commands the matrix does not allow.

Blocked attempt test records

Test records prove that the restrictions work. Run planned attempts from a non-authorized role to execute a restricted privileged command remotely, and to open restricted security information, then save the request, the denial and the log entry for each. Repeat the tests after material changes and keep the results with the date, tester and environment. Do not run these tests against production without a change window and rollback plan, and do not count a test as passed unless the denial is shown in the logs.

Access review records

Periodic access reviews confirm that each person holding remote privileged rights still needs them, and that roles still match the matrix. The record lists reviewed accounts, the reviewer, decisions to keep, change or remove, and evidence that removals were completed. Tie the review to staff changes and role transfers so departing or reassigned administrators lose remote privileges promptly. Ask the reviewer to sign the record, since assessors expect a named accountable person.

What meeting AC.L2-3.1.15 costs in money and effort

This table breaks down the cost of meeting AC.L2-3.1.15 into its components, showing who is paid for each, whether it is one-time or recurring, what drives it up, and how to keep it down. Read it as a checklist for a written quote, since most of the effort is internal and labor-based. No prices or durations are given because none were supplied for this requirement; confirm them against your own scope.

Cost component	One-time or recurring, and who is paid	What drives cost up	How to keep it down
Inventory of privileged commands and security-relevant information	One-time for the initial inventory, then recurring on change. Internal engineers, possibly a partner.	Number of systems, platforms and administrative tools in scope; undocumented scripts and vendor consoles.	Start from one system boundary, reuse existing privileged-role lists, and keep the inventory in version control.
Authorization matrix design	One-time, then recurring on role changes. Internal security and IT leads.	Number of privileged roles; overlap between roles; exceptions for vendors and emergency access.	Limit roles to a small, defined set and state a default of no remote execution unless documented.
Role and gateway configuration	One-time build, recurring tuning. Internal platform engineers or an implementation partner paid under a fixed-scope agreement.	Number of remote access paths and gateways; differences between Linux, Windows and network device administration.	Route privileged remote access through a single managed access point so one configuration covers most roles.
Session logging and log retention	Setup is one-time; storage and review are recurring. Internal operations staff, plus storage costs for logs.	Volume of privileged sessions; retention period set by the organization; whether logs are centralized.	Log only the security-relevant events needed to show authorization, and store them in an existing log platform where possible.
Testing of enforcement	One-time before assessment, then periodic. Internal testers or external security testers.	Number of roles and systems to test; whether tests cover negative cases where a non-authorized user is denied.	Test a representative sample of roles and document the method so repeat tests take less time.
Evidence upkeep	Recurring. Internal compliance or GRC staff.	Frequency of access changes; number of configuration screenshots, exports and records kept current.	Generate evidence from configuration exports and logs on a schedule rather than by hand.
External review or consultant support	Optional, one-time or recurring, paid by fixed scope or retainer. Consultant or implementation partner.	Team inexperience with NIST SP 800-171A objectives; number of systems in the assessment boundary.	Ask for a written scope that names the systems, roles and deliverables, and confirm the consultant does not perform the assessment.
Assessor time for interviews and sample review	Paid by the organization to an independent assessor, one-time per assessment cycle. The assessor does not work for the organization's consultant.	Number of administrators interviewed; number of privileged sessions sampled; how complete the records are.	Have administrators able to explain the authorized commands and sessions, and keep records in final form before the assessment.
Licenses and tools	Recurring if new purchases are needed. Software vendors. Most organizations already own a remote access gateway, directory service or log platform.	Whether existing identity, gateway and logging tools cover the requirement; new session recording features.	Inventory tools already owned first. Open-source options exist, but confirm each platform's capabilities before relying on it.

Which open-source tools support remote access enforcement and where they stop

Open-source network and web security tools can enforce parts of the remote access path for AC.L2-3.1.15, but none of them decides which privileged commands a person may run remotely. That decision belongs to the organization and must be written down in the roles and permissions documentation, then enforced by the systems that execute those commands. Treat these tools as supporting controls that restrict where remote administrative sessions can originate and what traffic reaches administrative interfaces. OPNsense is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol. Its aliases group addresses, which lets you define a single list of administrator workstations or jump hosts and allow only that list to reach administrative ports. Rules can log each match for review in the live log view. This supports the remote access path and produces traffic records, but it cannot tell whether a permitted administrator is running an authorized command. Confirm the rule set, alias definitions and logging options against your own configuration and the OPNsense documentation before you cite them as evidence.

Coraza is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It can help protect web-based administrative consoles, such as a browser interface that issues privileged actions, from common attacks including SQL injection, cross-site scripting and code injection. Coraza inspects HTTP requests and does not authorize privileged commands, assign roles or record which administrator approved an action. Its rule and integration support depends on the proxy you place it behind, so verify the supported integrations and rule configuration in the Coraza documentation for your environment. Both tools are licensed under open-source terms (OPNsense under BSD-2-Clause and Coraza under Apache-2.0), which affects how you can deploy and modify them but not whether they satisfy the requirement. Before relying on either tool, test a sample privileged session in a staging environment and confirm the logs show the expected source, destination and blocked attempts. Keep the role documentation, the enforcement configuration and the logs together as evidence for the assessor.

Who owns the authorization decision, who configures it and who assesses it

Your organization owns AC.L2-3.1.15. Leadership, the security function and the system owner decide which privileged commands may be run remotely and which security-relevant information may be reached remotely. Those decisions are the authorization itself, and no outside party can make them for you. The assessment objectives in NIST SP 800-171A ask whether the organization identified these commands and information and authorized them, so the decision record has to exist in your own documents before any assessor arrives.

Authorization decision: A named owner approves each remote privileged command and each category of security-relevant information, with the reason and the conditions attached.
Role matrix: You define which roles may perform those remote actions and which roles may not, and you keep the matrix current as staff change.
Enforcement settings: Your administrators or your partner's engineers configure the gateway and logging, but you approve the settings and the change record.
Signed procedure: A remote privileged access procedure is approved, dated and version-controlled, and staff are trained on it.
Periodic review: Someone accountable re-checks the list of authorized commands and roles on a set schedule and after major system changes.

Check that your signed procedure names the owner of each decision and that the role matrix matches the enforcement configuration.

Where organizations fall short on privileged remote access and how to close each gap

Most gaps under AC.L2-3.1.15 are not missing policies. They are policies that never reached the configuration, or configurations that cannot show who ran what. Each card below names one gap, the action that closes it, and the evidence an assessor will ask to see.

Remote privileged sessions open by default

Administrators can run any privileged command over a remote session because no one ever listed which commands are authorized for remote use. Assessors look for the authorized list first, because 3.1.15 starts with identifying the privileged commands. Close the gap by writing the list, marking each command as local-only, remote-permitted, or remote-with-approval, and removing default remote rights from admin groups. Evidence: the signed command list and the remote access policy that references it.

Roles written down but not enforced

The access matrix says a network engineer may run firewall changes remotely, but the remote gateway grants every domain admin the same session. Assessors test the mechanism, not the document. Map each documented role to a group in your identity provider, bind remote execution rights to that group, and test a denied attempt from an out-of-role account. Evidence: group membership exports, gateway policy configuration and test records showing denial.

Shared administrator accounts used by vendors

A managed service provider logs into remote tools with a single shared administrator login, so no session can be tied to one person. This breaks both the authorization and the traceability expected for privileged remote work. Require named accounts for every vendor technician, route vendor sessions through a jump host that issues per-session credentials, and retire the shared login. Evidence: the vendor account roster, jump host session records and the removal record for the shared account.

Remote sessions not linked to a person

Logs show that a privileged command ran over SSH from a particular address, but not which person initiated the session. Without that link, the audit trail cannot support the authorization decision. Record the authenticated identity, session start and end, source device and each privileged command in a central log, and confirm that timestamps match across systems. Evidence: sample session records traced from a command back to a named user and an approved role.

Procedure describes intent, not mechanism

The procedure says remote privileged work should be limited to approved staff, but it never names the control that enforces it. Assessors then have nothing to test. Rewrite the procedure so each step names the system that performs it, such as the gateway rule, the role group, or the logging setting, and state who approves exceptions. Evidence: the revised procedure with named enforcement points and a record of one walkthrough showing each step working.

Authorization matrices left stale

The matrix still lists a contractor who left last year and omits a system added during a migration. Remote privileged rights drift because nobody links personnel and system changes to the matrix. Assign an owner, tie matrix review to joiner, mover and leaver events and to each change request that adds a system, and record the date of each review. Evidence: dated review records, change tickets that reference the matrix and removal records for departed staff.

Common questions about AC.L2-3.1.15 cost, effort and outside help

How much effort does AC.L2-3.1.15 take compared with other access control requirements?

AC.L2-3.1.15 is usually a small piece of work compared with the broader access control family, because it covers one narrow question: which privileged commands and which security-relevant information may be reached remotely, and who may do it. The assessment breaks the requirement into four objectives, so the effort is mostly in deciding the scope and documenting it, not in building new technology. The work grows when many administrators use remote shells, when privileged tools sit behind several remote paths, or when no one has ever written down which roles may run commands remotely. Requirements such as AC.L2-3.1.1 and AC.L2-3.1.5 touch every account and every privilege in the environment, so they generally take more effort. Ask your team to inventory remote privileged activity first, since that inventory sizes this requirement more accurately than any general comparison.

Can we implement AC.L2-3.1.15 in-house without an outside firm?

Yes, an organization can implement AC.L2-3.1.15 with its own staff, because the requirement is about policy, role permissions and enforcement inside systems the organization already runs. The organization owns its controls, and it can write the authorization documentation, configure role-based permissions and collect logs itself. Outside help is usually considered for the parts that need specialist configuration time, such as tuning a firewall, aligning a privileged access tool with the documented roles, or preparing evidence packages for an assessor. Independent assessors and certification bodies must still perform the assessment, and no implementation partner can issue a report or certificate. Confirm internally whether staff have the time and skills to keep the evidence current, because stale documentation is a common reason this requirement fails review.

What does the internal team need to provide for AC.L2-3.1.15?

The internal team needs to supply the decisions and the proof, and an outside partner cannot make those decisions on its behalf. Expect to provide:

A list of privileged commands and security-relevant information that administrators may reach remotely, with a named business reason for each.
Role definitions that state which roles may run those commands remotely and which may view that information.
Access to the remote access gateways, identity systems and firewall or audit logs so enforcement can be shown.
Named administrators and security staff who can explain the process during interviews, since assessors test understanding as well as configuration.

Documentation must be in final form, not drafts, before an assessor reviews it. Plan for a named owner who keeps the records current after the first review.

How long does it take to be ready for AC.L2-3.1.15?

No fixed duration applies, because readiness depends on how many remote paths exist and how mature the current documentation is. The main drivers are the size of the privileged remote estate, the number of remote access routes, whether roles are already defined, and whether logs can show each remote privileged session. An organization with clean role definitions and one managed remote gateway will generally move faster than one with several legacy remote tools and no written authorization. Ask any implementation partner for a fixed-scope plan that lists the systems in scope, the deliverables and the dates, agreed in writing before work starts. Treat any number quoted without that scope as a guess.

Can AC.L2-3.1.15 go on a POA&M, and what are the rules?

Under the CMMC Level 2 scoring rules, AC.L2-3.1.15 is worth 1 point and is not on the exclusion list, so it may be placed on a plan of action and milestones (POA&M) when an organization reaches Conditional Level 2 status. The organization must have a score of at least 88 of 110 (0.8) to use that route, and it must close the open item within 180 days. Requirements on the exclusion list cannot be deferred this way, so confirm the current list in the eCFR text of 32 CFR 170.21 before relying on this. A POA&M is a short-term tool, not a way to avoid the control, and the item still needs real remediation evidence at closeout. Speak with your contracting officer or an authorized assessor about how your specific contract treats a Conditional status.

What changed with the Phase II suspension, and how does it affect timing?

On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 certification assessments for applicable contracts. A 60-day review by a CMMC Reform Task Force followed. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place, so the security expectations for AC.L2-3.1.15 have not been lifted. The DoW CIO's About CMMC page indicates that implementation is paused in Phase 1 and may only require self-assessments at Levels 1 and 2, while the eCFR text still shows the original four-phase schedule. Confirm the current status with the contracting office and the official DoW pages before setting a certification date, and keep your evidence ready regardless of the schedule.

How DeployOpen scopes and prepares privileged remote access evidence

DeployOpen helps defense contractors prepare the systems, documentation and enforcement evidence behind AC.L2-3.1.15 Privileged remote access. We prepare and document the controls inside your own environment, while your organization owns the controls and an independent assessor makes any determination.

How we scope

Confirm which privileged commands and security-relevant information the written scope covers for remote use.
Identify every remote access path to the CUI environment, including hosted infrastructure and cloud administration consoles.
Agree in writing which roles may run privileged commands remotely, and which evidence each deliverable will include.

How we build

Configure remote administration so privileged commands are restricted to documented roles and enforced through system controls.
Set up firewall rules and address aliases that limit remote administrative sessions to approved sources, with rule-match logging enabled.
Test enforcement by attempting remote privileged actions from unauthorized roles and recording the results.

How we hand over

Deliver the authorization documentation listing permitted privileged commands, roles and remote information access.
Provide configuration exports, role permission records and log samples that show the enforcement in its final form.
Walk your team through the evidence so they can explain it to the assessor, who tests it independently.

How we support

Offer ongoing support as a retainer to review role changes and keep the documentation current after go-live.
Recheck enforcement settings after upgrades, configuration changes or staff changes that affect privileged access.
Confirm with your assessor and your own environment which evidence formats they accept before work begins.