SC.L2-3.13.3 Role separation: requirements and evidence

What SC.L2-3.13.3 role separation asks for and why it fails audits

If you are the compliance lead or engineer responsible for this requirement, the short answer is that SC.L2-3.13.3 asks you to separate user functionality from system management functionality, so that administrative interfaces are not reachable by general users and administrators use them only for administration. The requirement text comes from NIST SP 800-171 Rev. 2, and it is worth 1 point in the CMMC Level 2 scoring. Assessors work from the three assessment objectives in NIST SP 800-171A: identifying user functionality, identifying system management functionality, and separating the two. Your organization owns the control. An independent assessor decides whether the evidence meets it.

The risk is simple to state. If an ordinary user can reach a console, an admin API or a configuration page, a single compromised or careless account can change security settings, create accounts, read logs or disable protections. The requirement is hard in practice because separation rarely exists by default. Shared hosts run user and management services side by side. Business applications often ship with administration screens inside the same interface users log into. Vendor appliances and platforms may keep default administrative accounts or open management ports on the same network segment as user traffic. Each of these needs a deliberate decision, not a vendor assumption.

Start by inventorying every management interface in the system boundary, including web consoles, admin APIs, database administration tools, hypervisor and firewall management, and built-in configuration pages. For each one, record who can reach it, from which network, and under which role. Then confirm the separation with a test from a standard user account, not only from a reviewer's view. Ask your team to document how the separation is enforced, whether by separate hosts, separate network paths, role-based access or application partitioning, because assessors look for both the design and proof that it works. Confirm the exact evidence expectations with your assessor before you rely on any single approach.

Which systems, roles and interfaces does role separation cover?

Role separation applies wherever a general user and an administrator can reach the same system, and the scope you draw determines how much work the requirement creates. The cards below cover the components assessors usually look at first and the scoping decision that changes the effort for each.

The CUI system boundary

Role separation only has to be demonstrated inside the system that stores, processes or transmits CUI, so the boundary definition sets the population of interfaces you must check. Document which hosts, applications and management paths sit inside the boundary in the system security plan. A shared identity provider or logging platform that serves CUI systems is usually inside the boundary too, so confirm its admin roles are separated before you exclude it. Decide the boundary first, then inventory every administrative path that falls within it.

Admin consoles and management interfaces

Web consoles, SSH access, and vendor management portals are the most common places where administrative functions are reachable from user workstations. Scope each console as its own item, because a console that is reachable from the general user network is a separation finding even if the admin account is protected. Check whether the console listens on a separate interface, port or subnet, and whether access depends on the administrator role rather than network location alone.

Application admin functions inside user-facing apps

When an application puts administrative screens (user management, configuration, audit settings) in the same interface as user tasks, the separation has to happen inside the application through role-based access. This is the case that changes the work most, because the fix may require code or configuration changes rather than network controls. Ask whether admin functions share a host, process or web application with user functions, and whether the application enforces the split or only hides menu items.

Hypervisors and cloud control planes

Hypervisor management and cloud control planes such as tenant administration consoles can give control over every workload they host, so they are high-impact administrative interfaces. Scope them as separate from user workloads, restrict them to administrator identities on a management network or through dedicated administrative paths, and keep user virtual machines from reaching the management plane. Confirm which cloud administrative roles exist and who holds them, since the separation depends on those assignments as much as on the architecture.

Network device management

Firewalls, switches and routers expose management interfaces that can change the security of every system behind them. Place these interfaces on a dedicated management network, restrict them to named administrator sources, and keep them off user segments. Firewall management software such as OPNsense can be restricted by listening interface and source address, and its rule changes should be reviewed in the live log view. Confirm that general users cannot reach the web interface or SSH service from their own network.

Third-party and managed-service administrator access

Vendors, managed service providers and support staff often hold administrative access that never appears in the internal role list. Decide whether vendor accounts are part of the system's administrative population, then confirm they use administrator roles only for the tasks in their contract and that user functions remain separate for their accounts too. Remote vendor sessions should be inventoried, time limited and logged. Ask your provider to show the administrative accounts it holds on your environment and how they are separated from its own general user access.

How an assessor tests the three role separation objectives

This table compares each NIST SP 800-171A objective for SC.L2-3.13.3 with the test an assessor runs, the evidence they ask for, and the gaps they most often find. Read it as a checklist: the requirement is MET only when every applicable objective is satisfied with final evidence, not drafts or plans.

Objective	Test approach	Evidence requested	Common findings
Identify user functionality	Assessor walks the system boundary and asks the organization to list the functions general users perform, such as application features, portals and reports.	Current inventory of user-facing functions mapped to the system security plan, with owners and access paths.	User functions are missing from the inventory, or the list is generic and does not match the systems in scope.
Identify system management functionality	Assessor identifies administrative consoles, configuration interfaces, privileged scripts and management APIs, then checks which are reachable from user accounts.	Inventory of administrative interfaces and privileged functions, with the roles or groups authorized to use each one.	Admin consoles are listed nowhere, or management functions share a login page or port with user functions.
Separate user functionality from system management functionality	Assessor attempts to reach administrative functions with a standard user account and a non-admin session, and checks that separation is enforced by configuration rather than by documented intent.	Test results showing denied access for user accounts, role or group configuration exports, and separate hosts, ports, URLs or network paths where used.	Standard users can open admin pages by direct URL, or administrators work from the same session and account they use for email and browsing.
Administrators act only through administrative roles	Assessor reviews which accounts hold admin rights and whether administrators log in with separate privileged accounts for administrative work.	Privileged account list, role assignment records, and a sample of admin activity showing use of the privileged account.	Administrators use daily accounts for system changes, or shared admin accounts make it impossible to tell who performed an action.
Application partitioning as potential evidence	Assessor reviews how the application is partitioned into user and management components, which SP 800-171A lists as a potential evidence source for this requirement.	Architecture diagrams, component separation documentation and deployment configuration showing the partition.	Diagrams show a partition that the deployed system does not follow, or the partition exists only for the front end.
Audit records as potential evidence	Assessor samples logs to confirm that administrative functions and access attempts are recorded and can be tied to a named user.	Audit log extracts for administrative actions, retention settings, and a sample tracing an admin action to its account.	Logs record the action but not the account, or administrative logs are not retained for the period the organization claims.
Scope and boundary consistency	Assessor checks that the functions and interfaces named in the other rows are inside the assessed boundary and that the system security plan describes them the same way.	System security plan sections and diagrams that match the inventories and test results.	Cloud consoles or vendor-hosted management portals are left out of the boundary without a documented reason.
Evidence in final form	Assessor confirms that every artifact used to show the objectives is finalized, dated and current at assessment time.	Approved versions of policies, diagrams and inventories, with revision history and the date of the last test.	Assessed evidence is a draft or was produced for the assessment, so the objective cannot be marked MET.

Evidence that shows user and admin functions are separated

An assessor testing SC.L2-3.13.3 looks for proof on both sides of the line: that user functions and management functions are identified, and that the separation holds in practice. The six artifacts below each answer one part of that question, and each needs a dated owner and a refresh routine so it reflects the system as it runs today.

Documented functional inventory

A written list of every function the system offers, split into user functionality and system management functionality, with the interface, role and host where each one runs. This is the first objective an assessor checks, since separation cannot be tested until both sides are named. Review it at each change to the application, plug-in set or administrative console, and record who approved the update. A draft inventory does not count as evidence, so mark it final, dated and signed before the assessment.

Role and permission exports

Exports from the identity provider and the application showing which roles can reach administrative functions, and which accounts hold those roles. The assessor will look for admin rights confined to admin roles, with no general user group carrying them through inheritance or a legacy group. Schedule a recurring export, store it with a timestamp, and compare each cycle against the approved access list. Confirm with your platform team how the export is generated, since a screenshot is weaker than a system-generated file.

Admin console network restrictions

Firewall rules, reverse proxy configuration or network segment definitions showing that administrative interfaces accept connections only from management subnets or jump hosts. Keep the rule set and the alias lists that define those subnets under change control so the restriction in place matches the restriction described in the system security plan. An assessor will often test whether a user workstation on the general network can reach the admin port, so the rule export should be paired with a reachability test result.

Separate admin accounts with logs

Evidence that administrators use dedicated accounts distinct from their everyday user identities, and that the logs record administrative actions under those accounts. An assessor will check that an administrator who logs in to a management function cannot do the same work from a standard account, and that the audit trail attributes each change to a named individual. Pull a sample of administrative events for a defined period and confirm each one maps to an admin identity. Requirements on audit records sit in the AU family, so cross-reference them here.

Change records for admin interface access

Tickets or change records that authorize granting, modifying or removing access to administrative interfaces, including the approver and the reason. These show that the separation is governed rather than accidental, and they tie access changes to the configuration management process. Keep a register of admin interface grants and match each grant to a record. An assessor will sample entries and ask whether any admin access appeared without an authorizing record, so gaps in this trail are a finding in their own right.

Negative test results

Documented tests in which a general user account attempts to reach each administrative function, both through the interface and by direct request to the underlying endpoint, and the system denies the attempt. Record the test date, the account used, the function tested and the observed result, and retest after each release or role change. Testing that only confirms admins can log in does not show separation. Results must be final and tied to the version tested, so keep them alongside the change records that introduced the version.

Separating user and admin functions, step by step

This sequence turns SC.L2-3.13.3 into a working separation: an inventory of what users and administrators do, a chosen separation method, restricted admin paths, dedicated admin accounts, a tested result, and a written record in the system security plan that an assessor can follow.

Inventory user and management functions
Start by listing every function the system performs for general users and every function used to manage it. Cover application features, administrative consoles, database management tools, hypervisor and cloud management portals, backup and monitoring dashboards, and configuration interfaces. The system owner and the platform engineers should review the list together, because the assessor will compare it against the boundary described in the system security plan. The output is a function inventory that names each function, its user population, and the interface through which it is reached. Mark any function that changes system settings, accounts, logs or security controls as a management function.
Choose the separation method for each function
For each management function, decide how it will be separated from user functionality. Options include running administration on separate hosts, exposing admin interfaces on separate network interfaces, placing them on a dedicated management network, or using role-based access controls inside one application so that only administrative roles see the admin pages. Record the method and the reason for each choice in a short decision table. A mix is normal, for example a separate management network for hypervisors and role-based access for an application's admin panel. The output is a separation design that ties each management function to one method.
Restrict admin interfaces to admin roles and networks
Apply the design so that administrative interfaces accept connections only from administrative roles and approved administrative networks. On a firewall such as OPNsense, this means rules that permit access to admin ports only from a management address alias and deny other sources, with each rule match logged for review. Inside applications, remove admin navigation and endpoints from non-admin roles and confirm that the server enforces the restriction, not only the user interface. Keep the configuration in version control so changes are traceable. The output is a set of configuration records and firewall rules that match the design from the previous step.
Separate administrator accounts from daily accounts
Give each administrator a second account used only for administrative work, and keep the everyday account for email, documents and general application use. The administrative account should be a distinct identity with its own authentication requirements, and it should not be used to browse or read email. This step matters because a general user who can reach an admin interface through a daily account has defeated the separation even if the interface is restricted. The output is an account register that lists each administrator, the daily identity, and the administrative identity, with the roles assigned to each.
Test access with a non-admin account
Test the separation from the perspective of a general user. Sign in with a standard account from a user workstation and attempt to reach every management function in the inventory, both through the application and directly by address or port. Then repeat the attempts from an administrative account on an approved administrative network to confirm that administration still works. Record each test, the account and source used, the result, and the log entry produced. An assessor may repeat these tests, so the record should be specific enough to reproduce. The output is a dated access test record with pass or fail results and remediation for any failure.
Document the separation in the system security plan
Describe the final design in the system security plan, including the function inventory, the separation methods, the admin networks and roles, the account model, and where the access test record is kept. Link the description to the boundary and network documentation so the assessor can trace the requirement to its implementation. Confirm with your assessor or the CMMC assessment guidance which evidence form they expect, and make sure the final version, not a draft, is what is presented. The output is an updated system security plan section for SC.L2-3.13.3 that names the evidence and the person responsible for keeping it current.

Where Coraza and OPNsense help, and where they stop

Network and web-layer controls can keep general users away from administrative interfaces, which is the outer half of SC.L2-3.13.3 Role separation. The cards below cover what two open-source tools can do at that layer and where the organization still has to build separation itself.

OPNsense restricts who reaches management ports

OPNsense is a stateful packet filter under the BSD-2-Clause license. Its rules pass, block or reject traffic by source, destination, port and protocol, and aliases let you group address ranges such as an administrator subnet. You can point a rule at the ports that serve admin consoles, such as a management web interface or SSH, and allow them only from that group. Confirm the rule syntax and alias behavior in the version you run, and test from a non-admin host to show the block works.

OPNsense logs rule matches as evidence

An assessor testing role separation will want proof that the restriction is enforced and monitored, not only configured. OPNsense can log each rule match, and those entries appear in the live log view for review. Keep the logging setting on for the admin-access rules, export or forward the entries to your central log store, and sample them over time. Confirm the retention and export options in your own deployment, because the built-in view alone may not meet your audit record needs.

Coraza limits access to admin paths

Coraza is a web application firewall under the Apache-2.0 license. It runs ModSecurity SecLang rulesets and is compatible with the OWASP Core Rule Set, and it has integrations for Caddy, HAProxy, Traefik and Nginx. Rules can match request paths such as an administrative console route and deny them unless the request meets conditions you define, for example a trusted source or an authenticated role header. Test each rule against real admin and general-user requests, because path matching alone is easy to bypass if the application serves the same function under another route.

Coraza does not separate application functions

Neither tool separates functions inside an application. A firewall or web application firewall decides which requests reach a service, but it cannot tell whether a logged-in user should be able to change system settings once the request is through. Role separation inside the application still depends on how the software assigns roles, how its admin functions are structured, and how its access control is configured. Ask the platform owner which functions are restricted to administrative roles and confirm this in the application itself.

Confirm each capability in your environment

Feature sets change between releases and deployments, so do not rely on this description alone. For each tool, record the exact version, the rule or ruleset you deployed, and the test you ran to show that a general user cannot reach an admin interface. Check whether your ruleset version and integration (for example, the Nginx or Traefik connector) support the matching you need. Keep these test results with the system security plan, since they are the evidence an assessor will ask for.

Pair network controls with administrator accounts

The intent of SC.L2-3.13.3 is that general users cannot perform system administration functions and administrators perform them only through their administrative roles. Network and web-layer rules support this by limiting where admin traffic can come from, but the separation also needs separate administrator accounts, role assignments and an audit trail that ties actions to a named person. Map each admin path or port to the role allowed to use it, and check that the role grants match that map. Your identity and access controls are a separate evidence set that must agree with the firewall rules.

What role separation costs in money and effort

This table compares the cost components of separating user functions from administrative functions for SC.L2-3.13.3, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Read it as a list of questions to put to any implementation partner or internal team before agreeing a written scope, since no price or duration is published for this work. The main takeaway is that open-source tools reduce license spend but not the engineering and evidence effort that the requirement mostly demands.

Cost component	One-time or recurring	What drives it up or down
Engineering time to inventory functions and redesign access	One-time, with revisits after changes	Number of applications and services, and whether admin functions are clearly separated from user functions in the design. Ask for the inventory method and the list of functions covered.
Licenses or tooling	Recurring for commercial products, none for most open-source components	Self-hosted open source removes license spend but not labor. Ask which components carry license fees and which are open source, and who maintains them.
Separate administrative accounts and role configuration	One-time build, recurring administration	Number of admin roles, identity provider design, and whether existing products bundle admin rights into general user roles. Ask how roles are reviewed and by whom.
Logging and audit record upkeep for administrative actions	Recurring	Log volume, retention period set by the organization, and how many systems feed the log store. Ask what evidence of administrative access is retained and how it is reviewed.
Remediating legacy applications with built-in admin roles	One-time, often the largest variable	Legacy apps that cannot separate roles, or that rely on shared admin accounts, may need configuration changes, wrappers or replacement. Ask for a per-application assessment.
Third-party or vendor administrators	Recurring	Vendor support staff with standing admin access raise scoping and contract work. Ask how vendor admin sessions are separated, approved and logged.
Independent testing of access controls	Recurring at each test cycle	Scope of testing and whether it covers both user and admin interfaces. Ask whether testing is performed by a party independent of the implementer.
Assessor sampling during assessment	Recurring at each assessment	Number of systems in the CUI boundary and the evidence already in final form. Assessors test the separation directly, so ask the assessor for its sampling approach before work begins.

Who owns role separation, what partners do, and where the auditor stops

Your organization owns the control. That means deciding which functions are user functions and which are system management functions, approving who may use each administrative interface, and writing the system security plan entry that describes how the separation works. Nobody outside the organization can make those decisions for it, and an assessor will look for evidence that the people accountable for the system made them.

Function inventory: Maintain a list of user-facing functions and system management functions for each in-scope system, including web consoles, database admin tools, hypervisor and cloud management planes, and network device interfaces.
Access decisions: Record which roles may reach each management interface and who approves exceptions.
System security plan entry: Describe the separation in plain terms, name the systems covered and link to the configuration that enforces it.
Ongoing review: Confirm that new applications and administrative tools are added to the inventory when they are deployed.

Before any assessment, confirm that the inventory and access decisions are signed off and dated, because draft documents do not satisfy the requirement.

Gaps that fail role separation in practice

Most role separation failures are not missing technology. They are admin paths that were left open, accounts that were shared, and proof that was never finalized. Each card below names one gap, how to close it, and the evidence an assessor would expect to see.

Admin consoles reachable from the user network

An administrative web console or management port sitting on the same network segment as user workstations lets any standard user attempt administrative functions. Close the gap by placing management interfaces on a separate administrative network or subnet and restricting access to named administrator sources. Evidence is a current network diagram, firewall rules showing the management ports are denied from user subnets, and a test from a user workstation showing the connection fails. Confirm the rule set in your own firewall, since the intent is that general users cannot reach administration functions at all.

Shared admin and user accounts

When administrators perform privileged work from the same account they use for email and web browsing, role separation exists only on paper. Close the gap by issuing each administrator a separate privileged account, restricting that account to administrative tasks, and requiring standard use for everyday work. Evidence includes the account roster showing distinct administrative identities, group membership reports, and audit records tying privileged actions to those identities. Ask whether any generic or shared login still performs administration.

Undocumented admin functions inside business applications

Many business applications ship with administrative screens, settings pages or API routes that are visible to ordinary logged-in users, even when the menu hides them. Close the gap by inventorying every administrative function in each application, mapping it to a role, and enforcing the restriction on the server side rather than only in the interface. Evidence is the function inventory, role-permission mappings, and results of a test where a standard user account is denied each administrative action. Assessors look for enforcement, not a hidden menu item.

Default vendor admin accounts left active

Platforms often install with default administrative accounts that remain enabled after deployment, giving anyone who knows the default credentials elevated access to the system. Close the gap by disabling or renaming default accounts, replacing default credentials, and confirming that privileged functions are granted only through defined administrative roles. Evidence includes the configuration baseline showing default accounts disabled, a list of active privileged accounts with owners, and a record of the hardening step. Confirm the specific default accounts with each vendor's documentation for the version you run.

No test showing a standard user is blocked

A role model that has never been tested is an assumption, and assessors expect to see a user with standard privileges attempt administrative tasks and fail. Close the gap by writing test cases for each administrative function and each management interface, running them with a standard user account, and retaining the results. Evidence is a dated test plan, the executed results showing the denied actions, and the audit log entries generated by the attempts. Repeat the test after significant configuration or application changes.

Evidence that exists only as an unapproved draft

Role separation documents such as an access matrix, an administrative procedure or a network diagram that were never approved or dated cannot show the control is operating. Close the gap by finalizing each document, assigning an owner, recording approval, and setting a review cycle tied to the system security plan. Assessors accept evidence only in final form, so a draft that describes the intended design will not satisfy the objective on its own. Confirm your internal document control process and keep the approved version alongside the test results.

Questions about effort, POA&M and doing role separation in-house

How long and how much effort does role separation take to implement?

No fixed duration or dollar figure applies to every environment, and no supplied source gives one for SC.L2-3.13.3. The effort depends on how many systems have administrative interfaces, whether those interfaces are already on separate hosts, ports, networks or accounts, and how many user-facing applications share a platform with their admin consoles. Organizations with a single well-documented application often need less work than those with several shared services. Ask any provider to break the quote into discovery, design, configuration changes, evidence capture and handover, and to state which items are one-time and which recur, such as periodic access reviews.

Can our team handle role separation without an outside partner?

Yes, many internal teams can do this work if they own the systems involved and have engineers who understand the administrative paths. The organization owns its controls, so the internal team makes the design decisions and produces the evidence either way. An outside partner can help with architecture review, hardening, documentation and evidence preparation, but it does not replace the organization's responsibility or the independent assessor's role. Teams that lack staff with spare time, or that run many legacy platforms, often find an external engagement with a written scope easier to manage.

What does the work need from our staff?

You need people who can name every user-facing function and every system management function on in-scope systems, and who can explain which accounts reach each one. Typically this includes system owners, network and identity administrators, application developers and whoever maintains the logging configuration. Expect time for interviews, for reviewing configuration exports and for testing that a standard user account cannot reach the admin interface. Assign a single owner to the evidence set so that policy text, configuration screenshots and test results stay consistent and in final form.

Can SC.L2-3.13.3 go on a POA&M?

Yes, under the conditions in 32 CFR 170.24 and 170.21. SC.L2-3.13.3 is a 1-point requirement that is not on the exclusion list in 32 CFR 170.21(a)(2)(iii), so it may be placed on a plan of action and milestones for Conditional Level 2 status if the overall score is at least 88 of 110. The closeout of that POA&M item is due within 180 days. A POA&M is a bridge, not a waiver, so the organization should still treat the gap as a priority and confirm the rule details with the current eCFR text before relying on it in a bid.

How does the Phase II suspension of 13 July 2026 affect this work?

The Department of War suspended CMMC Phase II on 13 July 2026, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The underlying NIST SP 800-171 Rev. 2 requirement still applies, and the Department said it will enforce Rev. 2 in the interim. Confirm the current status on the DoW CIO About CMMC page, because the eCFR phase schedule text and the official page may not match. Separating user and administrative functions is useful regardless of which phase applies.

Which parts of role separation will an auditor not do for us?

An assessor tests and reports on your controls but does not design, configure or document them. Assessors will not write your separation design, change your admin consoles, build the test accounts or prepare the evidence package for you. Under the CMMC framework, a C3PAO or other independent assessor issues the assessment result, and the organization's Affirming Official signs the affirmation. An implementation partner can prepare systems and evidence, but it does not issue reports or certificates. Ask any provider to confirm in writing which tasks it performs and which remain with the organization and the assessor.

How DeployOpen separates admin paths and prepares evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so administrative interfaces sit apart from general user access and can be shown to an assessor. We prepare the systems and evidence; your organization owns the control, and only an independent C3PAO issues a certification result.

How we scope

Engagements are fixed-scope, with systems, admin interfaces and deliverables agreed in writing before work starts.
We inventory which user-facing and system management functions exist on each platform in the CUI boundary.
We identify where administrators and general users reach the same interface, network segment or hostname today.

How we build

We place admin consoles on separate hosts or network segments, restricted to named administrative roles and jump paths.
We configure application-level role separation so general users cannot reach system management functions.
We test separation by attempting privileged actions from standard user accounts and recording the denied results.

How we hand over

We deliver a written role separation design showing which functions and interfaces are assigned to which roles.
We export access rules, role definitions and audit records that show the separation in effect, for your evidence file.
We document the procedure administrators follow and the test steps your team can repeat after changes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, so role separation stays intact after platform updates.
We re-test separation whenever new administrative features, roles or interfaces are added to the environment.
Questions on assessment objectives are answered with your assessor's expectations in mind, though the final judgment rests with the assessor.