What SC-11 trusted path requires and why it is rarely selected
SC-11 requires a physically or logically isolated communications path between users and the system's trusted components, and users must be able to invoke that path at least for authentication and re-authentication. No SP 800-53B baseline includes it, so an assessor will only test it if your organization selected it through tailoring or an overlay, or if a contract or authorizing official named it. If that is your situation, start by pulling the exact control text for your release from the NIST catalog and checking whether your system authority already selected it, because the answer decides whether any further work is needed. The risk SC-11 addresses is spoofing. A user types a password into a login prompt, but malicious software running on the same workstation or in the browser could imitate that prompt and capture the credential. A trusted path closes that gap by giving the user a channel that other software cannot imitate or intercept. The control is hard to satisfy because it forces two definitions. You must name which components are trusted (for example, the login service, credential store or security functions) and what the channel physically or logically consists of, then show that users can reach it on demand. For a web application or a hosted identity service, that boundary is often unclear, which is why many systems never take the control on.
SC-11 has two organization-defined parameters. The first sets which security functions and trusted components the path protects. The second sets which user actions invoke the path, such as sign-in and re-authentication before a sensitive action. Defining them in writing before an assessment is the most useful step you can take. The one enhancement adds the requirement to show that the path is used in a way that is distinguishable from other channels, so a user can tell when they are speaking to the trusted component. Confirm the wording of each parameter and the enhancement against the Release 5.2.0 catalog, then decide, with your assessor, whether your identity provider and administrative consoles can meet it or whether the control should be documented as not selected with a justification.
Which systems and login paths SC-11 applies to
SC-11 applies only when an organization selects it through tailoring, a contract or an overlay, because no SP 800-53B baseline and no FedRAMP Rev5 Class B, C or D baseline requires it. Scoping starts by naming the trusted components the channel protects, then the user paths that must use it, then the systems that fall outside the decision.
Login services and credential prompts
Start with every place a user types a password, PIN or second factor into a system component that is trusted to verify it. This includes the identity provider login page, operating system logon screens, and re-authentication prompts for privileged actions. Confirm which of these the system itself renders, because a prompt served by a third-party page or browser extension sits outside the system's trusted components and cannot be bound to the channel by the organization.
Administrative consoles and management interfaces
Administrative consoles, hypervisor management pages and configuration interfaces for security functions are the most common candidates for a trusted path. Record which consoles accept privileged credentials and whether they are reachable only through separate access paths. Pair this list with the SC-2 separation decisions so the trusted path covers management functions that users must not reach through ordinary application traffic.
Security function interfaces
Identify the interfaces through which users change access enforcement, audit settings, logging policy or key material. Each of these is a security function whose integrity matters, so the organization should decide whether a user-facing path to it needs an unspoofable channel. Document the decision and the rationale, since an assessor will ask why a given security function is or is not covered.
User paths that must use the channel
Once the trusted components are named, list the user paths that reach them, including local console access, remote desktop, web sign-in and any API used for credential entry. The channel only protects a path that users are required to invoke, so note which paths are mandatory for authentication and re-authentication and which remain optional. Verify each path in the system configuration rather than relying on the design diagram alone.
Systems outside the trusted path scope
Document the systems that do not perform authentication or security functions for users, such as batch processing nodes, internal data pipelines and components with no interactive login. Recording these exclusions with reasons keeps the scope defensible during assessment. Revisit the list whenever a new login service or console is added, because a system that was out of scope can gain a trusted component through an upgrade or integration.
Where the requirement originates
Confirm whether SC-11 comes from a tailored baseline, a contract clause, an agency overlay or an internal policy, since the source determines who sets the parameters. FedRAMP Rev5 Classes B, C and D do not require it, so an organization operating under FedRAMP alone should not assume it applies. Ask the contracting authority or overlay owner to state the requirement in writing before scoping begins.
How an assessor tests SC-11 under SP 800-53A
This table maps the SP 800-53A Release 5.2.0 assessment elements for SC-11 to what an assessor examines, whom they interview and what they test. Use it to prepare evidence before an assessment begins, since each row names an artifact or behavior the assessor will ask to see.
| Assessment element | What the assessor does | Evidence that passes | Where it usually fails |
|---|---|---|---|
| Determination statement 1: trusted path definition | Confirms the organization has defined the trusted communications path and the trusted system components it connects to users | Design documentation naming each trusted component and the isolated path users invoke for authentication | Trusted components are never listed, so the assessor cannot tell what the path protects |
| Determination statement 2: user invocation | Checks that users can invoke the trusted path at least for authentication and re-authentication | Test record showing a user starting the trusted path and completing sign-in or re-authentication through it | No tested invocation path exists, or the path is only described and never exercised |
| Examine: independent testing results | Reviews assessment results from independent testing organizations covering the path | Prior independent test reports that address the path, with dates and scope | No independent testing has covered the path, or results do not mention SC-11 |
| Examine: system design documentation | Reads architecture and design material to confirm the path is isolated, physically or logically | Architecture diagrams and design notes showing the path bypasses untrusted components | Diagrams show a generic login page with no isolation boundary or trusted component named |
| Examine: configuration settings and documentation | Checks configuration that enforces the path and the documents that explain those settings | Exported configuration with the parameter values the organization set for SC-11, plus matching procedures | Parameter values are missing or differ from what the design documents describe |
| Examine: system audit records | Looks for logged invocations of the trusted path and related authentication events | Audit entries that show path invocations tied to user identity and time | Invocations are not logged, so the assessor cannot confirm the path is used |
| Interview targets | Asks system owners, security engineers and identity administrators how the path works and who maintains it | Consistent answers from owners, engineers and administrators that match the documents | Staff describe different paths, or no one can name the trusted components |
| Test: user invocation of the path | Has a user attempt sign-in and re-authentication through the trusted path and observes the result | Reproducible test steps, screenshots or logs showing the path is isolated from untrusted software | Test is run only by the implementer, or the test does not cover re-authentication |
| Common finding: undocumented trusted components | Notes trusted components that appear in configuration but not in design documentation | Inventory of trusted components kept in step with the design and configuration baseline | Components added during upgrades are never recorded in the design documents |
Implementing a trusted path step by step
This sequence turns SC-11 from a control statement into a tested, documented trusted path that users can invoke for authentication and re-authentication. Each step produces an artifact an assessor can examine, so the organization can show the path exists, works and stays isolated.
Identify trusted components and set parameters
The system owner and security team list the components that must sit on the trusted path, such as the login service, credential handling, and any security function that accepts user input for authentication. They then fill in the two organization-defined parameters for SC-11 by stating which functions the path must support and which user actions must invoke it, including re-authentication. The output is a component list with the parameter values recorded, reviewed and approved by the authorizing official or delegate. The step is done when every trusted component has an owner and each parameter has a written value an assessor can test against.
Select the isolation mechanism
The architect chooses whether the path will be physically or logically isolated, based on the components' risk and the threats in the system's risk assessment. A logical choice might use a dedicated authentication network segment, separate hosts and restricted protocols, while a physical choice uses dedicated hardware or terminals. Related controls such as SC-2, SC-3 and SC-32 often shape this decision, so the team should confirm how they interact before committing. The output is a short decision record naming the mechanism, the reasons for it and the residual risks accepted. The step is complete when the decision is approved and traceable to the risk assessment.
Design the invocation path for authentication
Engineers document how a user reaches the trusted component for sign-in and re-authentication, including which interfaces, ports and protocols are used and how the path avoids being redirected or spoofed by untrusted software. Where an open-source identity provider such as authentik or FreeIPA handles sign-in, the design states which parts of the flow stay inside the isolated path and how applications delegate to it. The output is a design document with data flow diagrams, trust boundaries and a list of blocked alternative routes. The step is done when a reviewer can trace every authentication flow from the user to the trusted component without crossing an unapproved boundary.
Harden and baseline the configuration
Administrators apply the configuration that enforces the design, such as restricting network access to the path, disabling alternate entry points and setting the protocols and certificates the path uses. They record the settings as a configuration baseline in version control, so changes are reviewed and reversible. Configuration assessment tools such as Wazuh can compare endpoints against policies to show the baseline holds over time, though the team should confirm the policies cover the specific settings chosen. The output is a baseline file and a deviation report. The step is done when the deployed settings match the approved baseline with no unexplained differences.
Test invocation, isolation and re-authentication
Testers attempt to reach the trusted component through every documented route and through routes the design should block, then confirm that sign-in and re-authentication occur only through the approved path. They also test whether a spoofed or intercepted prompt can capture credentials, and whether the path still works when the system is under the load and failure conditions the design expects. Independent testers provide the strongest results, and their findings feed back into the design. The output is a test plan, scripted test cases and a signed test record listing each result. The step is complete when every test case has a recorded outcome and every failure has a tracked fix or accepted risk.
Record design and test evidence for assessment
The compliance lead gathers the decision record, design document, configuration baseline, test record and audit records showing the path being used, then maps them to the examine objects in SP 800-53A for SC-11. Evidence is stored under version control or a document management system with dates, owners and approvals visible. The organization owns this package, and an independent assessor decides whether it is sufficient. The output is an assessment-ready evidence folder and a short cross-reference table. The step is done when someone outside the project can locate each artifact and confirm what it shows without asking the team for explanation.
Schedule review after changes
The system owner sets triggers for re-review, such as a change to the identity provider, a new application that joins the sign-in flow, a change to the isolation mechanism or a significant security finding. Each trigger reopens the affected steps, and the design, baseline and test record are updated together. The reviewer confirms the change does not weaken isolation or the invocation path. The output is a change log entry linked to the updated artifacts. The step is complete when every change to the trusted path has a recorded review, and the evidence folder reflects the current state of the system.
Options for the channel: identity providers, secure attention and console paths
For web applications, the most common approach is a dedicated identity provider that owns sign-in. Users authenticate once at a separate login service, and applications delegate authentication to it instead of collecting passwords themselves. authentik is an example of this model: it acts as an identity provider for applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so each application hands the sign-in step to authentik. The trusted path question then becomes whether the login pages, the identity provider and its administrative interface are reached over a channel that the application and the user's browser cannot impersonate.
- Separate login hostname: Serve the sign-in pages from a dedicated host with its own TLS certificate, so users can see where they are authenticating.
- Delegated protocols: Confirm which protocol each application uses (for example OpenID Connect or SAML) and that the application does not present its own password form.
- Administrative separation: Keep the identity provider's administration interface on a path that ordinary application users cannot reach.
- Provider-side logging: Record authentication events at the provider so the trail does not depend on each application.
Confirm with your assessor, using the configuration you have actually deployed, that the login path meets your isolation requirement, since the protocol choice alone does not establish it.
On Linux and UNIX hosts, authentication usually runs through the operating system's login stack, such as the local console login, pluggable authentication modules and remote directory services. FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, so users authenticate to the directory and obtain tickets that services accept. The trusted path concern here is whether the login prompt that a user sees is the one the operating system actually presents, and whether a process running on the host can imitate it to capture credentials.
- Directory-backed authentication: Use FreeIPA or a comparable directory so that host logins, sudo rules and service tickets follow one identity source.
- Console and SSH entry points: List every way a user can reach a login prompt on the host, including the local console, SSH and any remote management interface.
- Re-authentication for privileged actions: Check that elevation prompts are issued by the operating system, not by a script or application running under the user's session.
- Configuration evidence: Keep the PAM and Kerberos configuration files under change control so an assessor can see the authentication path as deployed.
Confirm with the vendor and your platform team how your distribution invokes the login and elevation prompts, because that determines what an isolated path looks like on your hosts.
Privileged console access covers the paths administrators use for out-of-band or emergency control: a physical console, a serial or lights-out management interface, a hypervisor console or a break-glass account. These paths often bypass the normal identity provider, which is why they are the highest-risk part of a trusted path design. A secure attention mechanism, such as a key sequence or a dedicated console session that the operating system or firmware controls, lets a user confirm that they are talking to the trusted component and not to a program that mimics the login screen.
- Inventory of consoles: Record each physical, virtual and management console, what it can authenticate, and who can reach it.
- Separate management network: Place out-of-band management interfaces on a restricted network path, consistent with the separation controls in the SC family.
- Break-glass accounts: Store emergency credentials under documented custody, and log every use.
- Session evidence: Keep console session records and their review results as assessment evidence.
Verify the secure attention behavior on each console type with the hardware or hypervisor vendor, because the availability and mechanism of a secure attention key vary by platform and are not established by this page.
Evidence that passes an SC-11 assessment
An assessor testing SC-11 Trusted path looks for proof that the trusted channel exists, is configured as designed, and actually works when a user authenticates or re-authenticates. The cards below cover the artifacts that prove each part, and the routine that keeps them accurate between assessments.
System design documentation
The design document should name the trusted components (for example the identity provider, credential prompt or login broker), show the path from the user to them, and state whether the path is physically or logically isolated. An assessor compares this diagram against the running environment, so every hop the diagram omits is a gap. Review it whenever the identity architecture or network routing changes, and record the review date and approver.
Configuration settings and their documentation
Capture the settings that make the path invoked and protected: which login entry points require the trusted path, how re-authentication is triggered, and how the identity provider is reached. For an open-source identity stack such as authentik, export the provider and flow configuration and keep it under version control. Each change should carry a ticket reference, so the settings in evidence match the settings in production.
Test records of invocation
Assessors expect records showing that a user invokes the trusted path for authentication and for re-authentication, not only for first sign-in. Run scripted test cases for each entry point, record the expected result, the observed result and the tester. Retest after every change to the identity or session configuration. A failed test with a documented fix is stronger evidence than a list of passing tests with no detail.
Audit records of trusted path events
Logs of authentication and re-authentication events show the path was used in practice. Confirm that each event records the user, the time, the entry point and the outcome, and that the time source is synchronized so records line up across systems. Forward these logs to a central store and set retention to match your audit policy. Sampling a few events per month during the review period gives you something concrete to show an assessor.
Independent assessment results
Where an independent testing organization has examined the path, keep its report with the date, scope and findings. Assessors treat independent results as a source of assurance because they come from outside the implementation team. Track each finding to a closed item or a plan of action with an owner and date. The report only counts for the scope it covered, so confirm that the trusted path, not just the login page, was in scope.
Keeping evidence current between audits
Assign an owner to a quarterly evidence review that checks the design diagram, exports the configuration, reruns the invocation tests and pulls a sample of audit records. Store each set under a dated folder so the history is visible. Ask your assessor early which methods they will use, because SP 800-53A procedures expect examine, interview and test evidence for the same control. Confirm the review cadence with your own governance team.
What meeting SC-11 costs in money and effort
This table breaks down the cost and effort components of meeting SC-11 Trusted path, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. No figures are given because none are supplied for this control, so use it to shape the scope you request in writing.
| Cost component | Who is paid or who does the work | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Design of the trusted path | Organization architects, with implementation partner input if engaged | One-time, revisited on major change | Number of trusted components and user entry points that must be covered |
| Identity and login tooling | Software vendor or open-source project; implementation partner for setup | Licensing recurs for commercial products; open-source identity tools remove that license spend | Choice of identity provider, number of applications integrated, and whether single sign-on already exists |
| Configuration and isolation testing | Implementation partner or internal engineers | One-time build, then retest after changes | Complexity of the isolation method and how many access paths must be proven |
| Security testing of the channel | Independent penetration tester or internal red team | Recurring, usually tied to the assessment cycle | Depth of scope, number of components, and whether testing covers spoofing of the channel |
| Evidence upkeep | Organization staff, often supported by a partner | Recurring with each assessment and system change | Level of automation for configuration evidence and audit log retention |
| Auditor or assessor sampling | Independent assessor, paid by the organization | Recurring per assessment cycle | Number of trusted paths in scope and how well evidence is organized before sampling begins |
| Ongoing monitoring of configuration | Organization or managed support retainer | Recurring | Frequency of configuration checks and the number of endpoints monitored |
Open-source tools that support the trusted path evidence
Open-source identity and endpoint tools can produce useful evidence for SC-11, but none of them, on its own, establishes that a channel is trusted. A trusted path is proven by how the system is designed and configured, and the tools only show parts of that design. The assessor will look at whether sign-in for the functions that matter actually runs through a path the user cannot be redirected away from. authentik (MIT) can help here because it acts as the identity provider that applications delegate sign-in to, through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers. Its provider configuration and application bindings are the records you would show to demonstrate which applications send authentication to the broker, and which do not. Confirm which protocols your applications actually use and whether each one is configured for the authentication flow you intend to document.
FreeIPA (GPL-3.0-or-later) supports the same question for Linux and UNIX hosts. It provides single sign-on through an MIT Kerberos KDC, so the evidence you collect is the realm configuration, the principals with authentication rights and the host enrollment records. Wazuh Security Configuration Assessment (GPL-2.0-only) checks monitored endpoints against YAML policies, mostly based on CIS benchmarks and extendable with custom policies, covering files, directories, registry keys and running processes. A custom policy can be written to check the settings that protect the login path on those hosts, and its pass or fail results are exportable evidence. Fleet (MIT) policies ask yes or no questions of devices as osquery queries, and the policies page shows which devices on each fleet pass or fail. Both tools are useful only if you define the checks yourself, document why each check represents the trusted path, and confirm with your assessor that the check is in scope.
Plan for the gap these tools leave. Each one reports on configuration and identity state, not on whether a user can actually reach a trusted component through an isolated channel, so the design decisions remain yours. Decide which functions require the trusted path, such as authentication and re-authentication under the control's organization-defined parameters, and record the channel design in your system documentation. Then test it: attempt to intercept or redirect the sign-in flow from a non-trusted application and keep the results. Ask your independent assessor which examine objects they will accept, since the assessment procedure refers to design documentation, configuration settings and audit records. Implementation partners such as DeployOpen can help configure and document these tools, but only the assessor can judge the result.
Who does what: your team, a partner and the assessor
Your organization owns SC-11 as a control decision. Your security leadership defines which system components are trusted for authentication and other security functions, which user actions must travel over the trusted path, and how the organization-defined parameters for the control are set. Your architects decide whether the path is physically or logically isolated, and they accept the residual risk if the isolation is only logical. Ownership also covers the policy statements and the decision to select SC-11 through tailoring or an overlay, since SP 800-53B does not place it in any baseline.
- Trusted component inventory: name the components (login service, credential store, re-authentication prompt) and record why each one is trusted.
- Parameter decisions: set and document the organization-defined values in the control implementation statement.
- Selection rationale: record why SC-11 was selected through tailoring or an overlay and which system impact or mission need drove it.
- Accountability: name the owner who answers for the control during reviews and after changes.
- Acceptance of residual risk: sign off where the path relies on logical rather than physical separation.
Before engaging anyone else, confirm that these decisions are written down, because an implementation partner or assessor can only test what you have defined.
An implementation partner such as DeployOpen can prepare the systems that realize the trusted path inside your own cloud accounts, data centers or air-gapped networks. Work typically covers configuring identity services so that sign-in and re-authentication flow through the designated components, isolating the administrative and sign-in paths from general user traffic, collecting configuration evidence, and preparing the documentation an assessor will examine. The partner does not decide the control, does not declare it compliant, and does not issue any report.
- Configuration of identity flows: route sign-in and re-authentication through the components your team named, using open-source identity providers where they fit.
- Isolation work: implement the network and access-path separation your architects chose, and document how it is enforced.
- Evidence preparation: export configuration settings, audit records and change history that show the path in operation.
- Testing support: run internal checks of the path before the assessor arrives, and record the results for your team to review.
- Documentation: draft the implementation statement and system design notes for your team to approve.
In a quote, ask which of these items are in the written scope, who maintains the configuration afterward, and whether evidence exports are delivered in a form your assessor can reuse.
The independent assessor tests whether SC-11 is implemented and effective, using the assessment procedure in SP 800-53A for the control. The procedure has two determination statements, and the assessor applies examine, interview and test methods to produce findings. Examine objects include assessment results from independent testing organizations, system design documentation, configuration settings with their documentation, and system audit records. Only the independent assessor issues the assessment report and findings. Neither your team nor a partner can issue that report, and the assessor's independence is the reason its findings carry weight.
- Examination: review design documents, configuration settings and audit records against the determination statements.
- Interviews: ask administrators and users how they invoke the trusted path and what happens when it is unavailable.
- Testing: attempt to observe or spoof the path, and confirm that users can invoke it for authentication and re-authentication.
- Findings: record which determination statements are met, partially met or not met, with supporting evidence.
- Independence rules: confirm the assessor has no role in designing or configuring the system it tests.
Before engaging an assessor, confirm its scope, the assessment procedure version it will use, and how it will treat evidence prepared by your partner.
Where SC-11 implementations usually fall short
SC-11 looks simple on paper: a trusted channel between the user and trusted components. In practice, gaps appear where the organization has not decided what counts as trusted, which login paths use the channel, and whether the channel still works after changes. The cards below cover the gaps assessors most often find and what closes each one.
Trusted components never defined
The control's organization-defined parameters require the organization to name the system components that handle authentication and other security functions. Many teams skip this step, so no one can say which path must be isolated. Start with a written list of trusted components, such as the identity provider, the login service and the credential store, and map each one to the hosts and services that run it. Check that the list matches the system security plan and the boundary diagram.
Channel covers only some login paths
A trusted path often works for the main web login but not for the admin console, SSH access, a legacy API or a break-glass account. An assessor who tests one path and finds another that accepts credentials without the isolated channel will record a finding. Inventory every authentication entry point, then confirm each one either uses the trusted channel or is documented as out of scope with a reason. Pair this with the identity provider configuration, since an application that delegates sign-in to a central provider inherits that provider's channel.
Re-authentication left out
The control expects users to reach the trusted channel for re-authentication as well as first sign-in. Teams often protect the initial login and then let step-up prompts, password changes or session re-verification go through an ordinary application path. Test each sensitive action that asks for credentials again, such as changing a privileged role or approving a payment, and confirm the prompt is served through the trusted path. Record the test results alongside the login tests so the evidence covers the full lifecycle of a session.
Configuration drift goes unrecorded
A channel that was isolated at deployment can be weakened by a later proxy rule, a new load balancer, a changed certificate chain or an updated identity provider release. If these changes are not logged, the organization cannot show the channel stayed intact over the assessment period. Baseline the relevant settings, monitor them for changes, and tie each change to a ticket that records the review. Ask the implementation partner to describe how configuration files and access paths are versioned and where the change history is stored.
No test evidence for the channel
Design documents describe the intended path, but assessors look for proof that it works. A missing test record is one of the most common reasons a control is rated as not satisfied. Write test cases for each trusted component and each login path, run them after every significant change, and keep the results with the date, the tester and the configuration version. Compare the results against the examine and test methods in SP 800-53A so the evidence maps directly to the determination statements.
SC-11 trusted path questions buyers ask
Is SC-11 trusted path required by default under NIST SP 800-53?
No. SC-11 is not assigned to any SP 800-53B baseline (low, moderate, high or privacy), so it applies only when your organization selects it through tailoring or an overlay, or when a contract, authorizing official or assessor requires it. Appendix C of SP 800-53 Rev. 5 lists it as implemented by the system and marks it as an assurance-related control. Before assuming it is in scope, check your system's baseline selection, any overlay you have adopted, and the written requirements of the customer or authorizing body. If it is selected, it becomes a documented control with an assessment, so the decision belongs in your system security plan.
What does SC-11 actually require an assessor to see?
SC-11 asks for a physically or logically isolated communications path between users and the system's trusted components, which users can invoke at least for authentication and re-authentication. SP 800-53A Release 5.2.0 assesses it through two determination statements using examine, interview and test methods. Typical evidence includes system design documentation showing where the trusted path sits, system configuration settings and their documentation, system audit records, and assessment results from independent testing organizations. Confirm the exact wording of the determination statements and assessment objects in the OSCAL procedures before you write your test plan.
How long does it take to implement SC-11?
No timeline figure is supplied for this control, so treat any number you hear with caution. The effort depends on how many user-facing trusted components your system has, whether an isolated authentication path already exists, and whether the design must be changed or only documented. Systems that rely on a single login front end may need less design work than systems with several administrative consoles. Ask any implementation partner for a written scope with deliverables and dates before work starts, and check the schedule against your assessment window.
What drives the cost of meeting SC-11?
Cost depends on scope and on what already exists. The main components are design review of the authentication and administrative paths, any changes to network or identity configuration, the time to produce design documentation and configuration evidence, and support during the independent assessment. Most of the cost is one-time, but monitoring, periodic review and re-testing after changes recur. Costs rise with the number of trusted components, the number of user populations, and the need for new isolation mechanisms. Ask for a quote that lists each component separately, names who performs each task, and states which items are one-time and which recur.
Can our own team implement SC-11 without outside help?
Often yes, if you have engineers who understand your authentication flows, network paths and administrative interfaces, and staff who can write design documentation and collect configuration evidence. The harder part is usually the independent view: an internal team may not spot every path a user could use to reach a trusted component. Outside help is most useful for reviewing the design, testing whether a user can reach trusted functions through an unintended route, and organizing the evidence package for the assessor. Decide early which tasks you keep in-house and which you contract out, and document that split in writing.
What do we need to provide to start SC-11 work?
Start with an inventory of user-facing trusted components, such as login pages, administrative consoles and key management interfaces. Add current architecture diagrams, network segmentation details, identity provider configuration, and the authentication and re-authentication flows that users follow. You also need access to test accounts and a change window for any configuration testing. Confirm which system boundary the control covers, since the answer changes with the scope of your authorization. A partner will normally ask for these items during scoping, and the written scope should list what you must supply and by when.
Can DeployOpen issue an SC-11 assessment or certify our compliance?
No. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms in your own infrastructure, and it prepares systems, controls and evidence for assessment. It does not issue audit reports, attestations or certifications. Only an independent assessor or authorizing body can determine that SC-11 is satisfied, and your organization owns the control decision. Where a platform such as an identity provider or directory service is part of the trusted path, we can document its configuration and test the path, but the assessor draws the conclusion.
How DeployOpen scopes and prepares SC-11 evidence
DeployOpen works on SC-11 as part of a fixed-scope engagement that defines which trusted components, user-facing authentication paths and security functions are in scope. We prepare the system, configuration records and evidence an independent assessor would examine, while the organization keeps ownership of the control decision.
How we scope
- Agree in writing which user authentication and re-authentication paths fall under SC-11 and which trusted components they reach.
- Confirm whether SC-11 is selected by your tailoring or overlay, since it sits in no SP 800-53B baseline.
- Record the two organization-defined parameters and the enhancement you decide to implement before work starts.
How we build
- Configure the open-source identity provider so sign-in for in-scope applications is delegated through a single, defined path.
- Document how the isolated channel is separated from ordinary application traffic, and where it is enforced.
- Set up configuration checks that flag drift in the sign-in path, so changes produce audit-ready records.
How we hand over
- Deliver design documentation and configuration settings that map each determination statement to a specific artifact.
- Provide test results from our security testing team, clearly labeled so your independent assessor can review them.
- Transfer administration runbooks so your own staff can operate and re-verify the trusted path after handover.
How we support
- Offer ongoing support and continuous testing as a retainer when your authentication path changes after the initial engagement.
- Review the SC-11 evidence set when related controls such as AC-16, SC-23 or SC-12 change in your environment.
- Keep the assessor-facing evidence current, and confirm with your assessor which artifacts they will accept.
