03.07.05 Nonlocal maintenance requirements and evidence

What 03.07.05 nonlocal maintenance requires and why it is hard to evidence

When a vendor engineer or internal administrator connects over a network to maintain or diagnose a system that holds CUI, the contract now expects you to show how that session is controlled. 03.07.05 requires you to approve and monitor each nonlocal maintenance and diagnostic session, use multi-factor and replay-resistant authentication to establish it, and terminate the session and network connection when the work is finished. The risk is that remote maintenance paths often sit outside the controls applied to people at the console. A vendor VPN, a support tunnel or a remote desktop left open after a ticket closes can give an outside party privileged access to CUI without anyone noticing.

The difficulty is evidence, not intent. The approval usually lives in a change or service ticket, the connection in VPN or jump host logs, the authentication in an identity provider, and the actual commands in the maintainer's own notes. These records rarely use the same identifiers, times or session references, so an assessor who asks you to trace one session from approval to disconnect may find gaps. Before any assessment, pick a sample of recent maintenance sessions and check whether you can rebuild each one end to end from records you already keep.

The Rev. 3 requirement traces to Rev. 2 requirement 3.7.5 and NIST classifies the change as minor, so existing Rev. 2 work carries over largely unchanged. Which version applies depends on the contract. The current DoW class deviation has contracting officers name Revision 2, and CMMC Level 2 is also assessed against Rev. 2, while a proposed FAR overhaul would require Rev. 3 with ODP values published by the DoW CIO. The rule was not final as of October 2026, so confirm the version in your contract and with your contracting officer before you build the evidence set.

Which maintenance sessions and systems fall under 03.07.05

Under 03.07.05, any maintenance or diagnostic activity that runs over a network is in scope, whoever performs it. The hard work is deciding which systems hold CUI, which third parties connect, and which maintenance paths exist, because those answers set the size of the control's footprint.

Vendor remote support sessions

A software vendor, integrator or managed service provider that logs into a system to troubleshoot, patch or reconfigure it is performing nonlocal maintenance, even when the work is routine. Check which vendor accounts exist, whether they reach systems inside the CUI boundary, who approves each session, and whether the session ends when the ticket closes. Record each approval so an assessor can match it to a session record.

Administrators working from home

An internal administrator who diagnoses a server or application from a home network or a personal device is also in scope. Nonlocal maintenance does not depend on who the person is or where the work happens. Confirm which administrative paths leave the office network, whether those paths require multi-factor and replay-resistant authentication, and whether the endpoint meets the same requirements as the systems being maintained.

Network device and hypervisor consoles

Management interfaces for firewalls, switches, storage arrays and hypervisors often sit on a separate management network and are easy to overlook. If an engineer reaches these consoles across a network, the session falls under this requirement. Inventory every management interface, identify which ones are reachable from outside the local segment, and confirm that jump hosts or bastion paths are approved and logged.

Cloud and SaaS management planes

Cloud consoles, infrastructure-as-code pipelines and SaaS administration portals can change systems that hold CUI without touching them directly. Treat a management plane as in scope when it can alter a CUI system, and confirm that privileged cloud sessions and automated service connections have approval, monitoring and termination rules. Ask the provider which of its own maintenance activity can reach your tenant.

Third-party connections to the CUI boundary

Each external network path that reaches a system inside the CUI boundary defines part of the scope, including site-to-site VPNs, partner-managed tunnels and monitoring agents that accept inbound commands. Map these paths against the system security plan and the CUI boundary diagram. A path missing from the plan is usually a path missing from the approval and monitoring process.

Scope that follows the system security plan

The scope for 03.07.05 has to match the system security plan and the CUI boundary the plan describes. If the plan omits a maintenance path, an assessor will test whether that path exists. Ask who owns the scope decision, which records prove each session was approved and monitored, and how new connections are added to the plan before they are used. Assessors typically review these records against the determination statements in SP 800-171A Rev. 3.

How an assessor tests 03.07.05 under SP 800-171A Rev. 3

This table walks through the six SP 800-171A Rev. 3 determination statements for 03.07.05 and shows what an assessor examines, interviews or tests, the evidence to prepare, and where findings usually arise. Read each row as a question the assessor will ask, then check that the evidence exists for the actual nonlocal sessions, not only in the written policy.

Assessment method	What the assessor checks	Evidence to prepare	Common findings
Examine: policy and procedures	Maintenance policy, remote access policy and the procedures for nonlocal system maintenance, including who approves a session and how it is monitored	Approved policy and procedure documents with owners and review dates, mapped to the nonlocal maintenance steps	Procedures describe remote support in general terms without approval, monitoring or session-end steps
Examine: maintenance and access records	Logs and records showing which nonlocal sessions occurred, who approved them, and when they ended	Session records with approver, vendor or user identity, start and end times, and the work performed	Sessions with no approval record, or logs that do not show when the connection closed
Interview: maintenance and security staff	Whether personnel with maintenance responsibilities understand the approval, monitoring and termination steps	Interview-ready walkthrough of one real nonlocal session from request to closure	Staff describe the process differently, or vendors connect through shared accounts
Interview: system administrators	How administrators enable, monitor and disable nonlocal maintenance paths and who can override them	Current list of nonlocal maintenance paths, their owners and the monitoring tools used	Administrators unaware of a remote tool installed for vendor use
Test: processes for managing nonlocal maintenance	That the approval and monitoring processes run as written during an actual or simulated session	Test results showing an approval gate, live monitoring and forced session end	Approval is informal, monitoring depends on a person noticing activity, or sessions stay open after work ends
Test: mechanisms for MFA and replay resistance	That multi-factor and replay-resistant authentication is enforced on the actual sessions, with the authentication requirements of 03.05.01 applied	Login traces showing a second factor and a replay-resistant method on each session, plus the configuration that enforces them	Policy requires MFA, but a legacy path, shared password or static code still allows entry without it

How to implement 03.07.05 in the order that produces evidence

This sequence moves nonlocal maintenance from informal remote access to a controlled, approved and logged process, so each session leaves records an assessor can examine and test. The organization owns the control, and an implementation partner can prepare the gateways, approval records and logs that the assessor later checks independently.

Define the approved maintenance paths
Start by listing every way maintenance or diagnostics can reach a system over a network, including vendor support tools, cloud consoles, jump hosts and service accounts used by administrators. The system owner, maintenance lead and information security lead agree which paths are approved, which systems each path may reach and who may use it. The output is a written approved path list tied to the system security plan, and the step is done when every path that appears in network and access logs is either on the list or blocked.
Route all nonlocal maintenance through named gateways
Configure the approved paths so that all nonlocal maintenance enters through a small set of named gateways, such as a bastion host, a privileged access broker or a managed remote session service. Systems in the CUI boundary should refuse maintenance sessions that bypass these gateways. The output is a gateway configuration record that shows the gateway names, the systems they serve and the firewall or access rules that enforce the routing. Confirm each product's capability for this routing in your own environment before you commit to a design.
Enforce multi-factor and replay-resistant authentication
Require multi-factor authentication for every nonlocal maintenance session and use authenticators that resist replay, such as WebAuthn or FIDO2 passkeys, rather than only static codes. Identification and authentication for maintenance accounts should follow the requirements in 03.05.01 and the related authenticator controls. Open-source identity platforms can enforce these second factors at login, for example authentik's authenticator validation stage supports TOTP apps, WebAuthn, FIDO2 passkeys and recovery codes. The output is a configuration export and a test log showing a session refused without the second factor.
Require an approved ticket before each session
Before any nonlocal maintenance session starts, the requester records a work order or change ticket that names the system, the task, the maintenance person or organization, the start window and the approver. The approver confirms the request against the approved path list and the authorization of the person before access is granted. The output is an approval record for every session, and the step is complete when a sample of sessions can be traced back to a ticket that was approved before the session began.
Log session start, activity and end
Turn on audit logging at the gateway and on the target systems so each nonlocal session records who connected, when, from where, which system was reached and what administrative actions occurred. Protect these logs from alteration and keep them where the reviewer can search them. Examples of logging features include the Nextcloud admin_audit app, which writes to an audit log file, and OpenBao audit devices, which keep JSON records of API requests and responses. The output is a set of session logs that match the approval tickets one for one, and you should confirm the exact events each product records in your own environment.
Enforce session termination at completion
When the approved work is finished, the session and the underlying network connection must end. Configure idle timeouts and automatic disconnection where the platform supports them, and have the maintainer close sessions and remove temporary access at the end of the task. The approver or system owner then closes the ticket with the end time. The output is a closure entry on each approval record, plus a test showing that a finished session cannot be reused and that the network connection is torn down.
Review sessions and keep the evidence current
Periodically compare the session logs against the approval tickets and the approved path list to find sessions with no approval, unapproved paths or sessions that stayed open. Record the review, the findings and the corrective action, and update the path list when systems or vendors change. The assessor will examine this record alongside the maintenance policy and interview system maintenance staff, so the review itself is part of the evidence. The organization owns this review, while an implementation partner can help build the reporting that makes it repeatable.

Which evidence satisfies 03.07.05 and how to keep it current

An assessor testing 03.07.05 follows one nonlocal maintenance session from approval through authentication to termination. The cards below cover the artifacts that prove each step, what the assessor samples, and how to refresh each one between assessments so the record stays consistent.

Nonlocal maintenance policy and procedure

This document sets who may start a remote maintenance session, which methods are allowed, how approval is requested, and how sessions end. The assessor compares the written procedure with what staff actually do, so the document must name the real tools, roles and ticket system. Review it at least annually and after any change to remote access tooling. Check that the procedure names the owner of each step, including who monitors active sessions and who closes them.

Approved remote maintenance paths

Keep a current register of every network path that maintenance can use, such as a bastion host, a vendor VPN or a jump server, with the systems each path reaches. The assessor checks that sessions only use listed paths and that unlisted paths are blocked. Reconcile the register against firewall rules and remote access gateway configuration each month, and record the date and reviewer of each reconciliation.

Maintenance approval records

Each nonlocal session needs a recorded approval that names the requester, the system, the task, the time window and the approver. The assessor samples approvals and traces them forward to a session. Keep approvals in the ticketing system with a unique identifier that is also written into the session record. Each month, sample a set of closed tickets and confirm that every one has a matching approval before work began.

Authentication configuration for maintenance sessions

Show the configuration that requires multi-factor authentication and replay-resistant factors for nonlocal maintenance, such as authenticator policies, identity provider flows and gateway settings. Replay resistance is the point most often missed, so the assessor will look at which factor types are actually accepted. Export the policy each quarter and store it with a hash or change record. Confirm that no shared accounts or single-factor fallbacks remain enabled for maintenance groups.

Session and access logs

Session logs show who connected, from where, when, to which system and what was run. The assessor uses them to confirm that monitoring happened during the session, not only afterward. Confirm that logs are forwarded off the maintenance host and retained for the period your procedure states. Each month, pick several sessions at random and check that the log entries match the approval window and the user named in the ticket.

Termination records

Termination evidence proves that the connection and any associated accounts ended when the work was complete. Keep records of session end times, gateway disconnect events and removal of temporary access. The assessor checks that no session remains open past its approved window. Each month, look for sessions still open beyond their window and confirm each was closed and documented, with the reason recorded.

What meeting 03.07.05 costs in money and effort

This table breaks down the cost components of meeting 03.07.05 for nonlocal maintenance, showing who is paid, whether each cost is one-time or recurring, what drives it up, and how to keep it down. No prices or durations are given because none are supplied for this topic, so use the table to shape your own scope and quote requests. The main takeaway is that open-source components can remove some license spend, but engineering, configuration and upkeep stay with you or your partner.

Cost component	One-time or recurring	What drives it	How to keep it down
Gateway and access tooling or licenses	Recurring if commercial; one-time if self-hosted setup	Number of maintenance paths, concurrent sessions and vendor licensing model	Limit maintenance to a small set of jump hosts and confirm license terms in writing before choosing a product
Identity and MFA setup	One-time build, then recurring administration	Number of maintenance accounts, second-factor types and whether an existing identity provider is reused	Reuse the organization's existing identity source and enroll second factors that replay-resistant sessions require, such as passkeys or hardware tokens
Engineering time to route and lock down maintenance paths	One-time, with periodic rework after system changes	Count of systems that receive nonlocal maintenance, vendor-managed equipment and network segmentation complexity	Inventory maintenance paths first and retire unused ones so fewer systems need custom routing
Approval workflow and records	One-time design, recurring operation	Volume of maintenance requests, number of approvers and whether tickets link to session logs	Use a single ticket template that records approver, purpose, systems and end time, and generate session records automatically
Evidence upkeep	Recurring	Frequency of assessments, log retention settings and how many systems produce separate evidence	Set log retention and export schedules once, and store evidence packages in a single location tied to the system security plan
External review or testing	Recurring or per engagement	Scope of testing, whether remote access paths are included and the depth of configuration review	Agree the tested paths and deliverables in writing so the review does not expand unexpectedly
Assessor sampling effort	Recurring per assessment cycle	How many maintenance sessions the assessor samples and how quickly your team can produce matching records	Keep session records searchable by date, system and person so samples can be answered without manual reconstruction

Which self-hosted open-source tools can support 03.07.05 evidence

The four tools below each produce records or enforce controls that an assessor can examine for 03.07.05. None of them satisfies the requirement by itself, because the organization still has to approve nonlocal sessions, define acceptable authentication, and show that connections end when the work finishes. Confirm every capability against the version and configuration you actually run.

authentik for maintenance gateway MFA

authentik is an MIT-licensed identity provider. Its authenticator validation stage checks enrolled second factors during login, including TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes. Placed in front of a maintenance gateway, it can require a second factor for every nonlocal session, which addresses the multi-factor part of the requirement. Confirm which factors your replay-resistance design accepts, because SMS, email and static recovery codes do not all meet the same standard, and recovery codes need their own approval and storage rules.

FreeIPA OTP tokens and RADIUS proxying

FreeIPA, licensed GPL-3.0-or-later, supports HOTP and TOTP tokens, including software tokens enrolled by QR code and hardware tokens such as YubiKeys. It can also proxy OTP checks to an existing RADIUS server, which helps during a migration when maintenance accounts still authenticate through older infrastructure. OTP tokens need a replay-resistance review, because a code that remains valid within its window is not the same control as a WebAuthn or FIDO2 assertion bound to the origin. Document how FreeIPA prevents reuse of a code and which token types the maintenance population is allowed to use.

Nextcloud admin_audit logs for platform maintenance

Nextcloud is licensed AGPL-3.0-only. Its admin_audit app writes additional event information to audit.log in the data directory, or to a path set with the logfile_audit setting. This evidence matters only when maintenance itself happens through the Nextcloud administration interface, such as an administrator's remote session changing app or server settings. Confirm that the app is enabled, that the log path sits on storage with restricted access, and that the log is forwarded to a system the maintenance reviewer can query. Without these checks, the log may exist but not show who connected and when.

OpenBao audit devices for API maintenance

OpenBao is licensed MPL-2.0. Its audit devices keep a detailed JSON log of every API request and response, including errors, and hash most sensitive values with HMAC-SHA256. For maintenance carried out through its API, this gives an assessor a per-request record to compare against approved maintenance tickets and session start and end times. Check that at least one audit device is enabled, that the log is protected from modification, and that the hashing setting still hides the values your reviewers must not see. The log shows what was done; it does not show that the session ended when the work was complete, so pair it with session termination evidence.

Who does what: your team, an implementation partner and the assessor

Your organization owns 03.07.05. The requirement asks you to approve and monitor nonlocal maintenance and diagnostic sessions, require multi-factor and replay-resistant authentication for them, and end the connections when the work is finished. Those are management decisions, so they stay with you even when a partner builds the technology. Your team decides which maintenance paths are allowed at all, which vendors and staff may use them, and what approval looks like for each session.

Approval rules: Decide who may request a nonlocal session, who approves it, and what details the request must contain, such as the system, the task and the planned window.
Permitted paths: Name the approved remote access routes for maintenance and state which ones are prohibited.
Policy and procedures: Write and sign the maintenance and remote access policy and the procedures that support them, since assessors examine these documents first.
Monitoring duties: Assign people to review session records and to confirm that connections closed when work ended.
Records: Keep the approval, session and termination records that show the control operated.

Before assessment, confirm that the named approvers and reviewers can explain the process in an interview, because the assessor will ask them directly.

Where organizations usually fall short on nonlocal maintenance

Most nonlocal maintenance failures are not missing technology. They come from maintenance paths that sit outside the normal identity controls, approvals that never reach the session record, and procedures written for an auditor rather than run by the people doing the work. The cards below describe where these gaps usually appear and what to check before an assessor does.

Shared vendor accounts

A vendor engineer connects with a shared login that several people know, so no session can be tied to one person. Under 03.07.05, the organization must approve and monitor each nonlocal maintenance session, and a shared credential makes that monitoring meaningless. Check whether every vendor user has a named account, that accounts are disabled between jobs, and that the identity provider records who signed in. Require individual accounts in the maintenance contract.

MFA on the VPN only

Multi-factor authentication is enforced on the corporate VPN, but the maintenance gateway or jump host accepts a password alone. Assessors test the mechanisms that actually open the session, so a single weak entry point can fail the requirement. Walk every path a maintainer can use, including direct SSH, vendor portals and web consoles, and confirm each one enforces a second factor and a replay-resistant method.

Approvals not linked to sessions

The change ticket says a vendor may maintain a database server on a given date, but nothing in the access logs ties the session back to that ticket. The requirement calls for approving and monitoring each nonlocal session, so the approval and the session record need a common identifier. Ask whether the gateway can require a ticket reference at login, and whether session logs can be searched by ticket, account and target system.

Sessions left open

A maintenance connection stays up for days after the work is finished, sometimes because the vendor disconnected the application but not the tunnel. The requirement expects connections to be terminated when nonlocal maintenance ends, so idle or forgotten sessions are a visible gap. Set session time limits, require the maintainer to end the session, and review active connections against open tickets at least as often as the approval window.

Policies describing unused process

The remote maintenance policy names an approval board and a monthly review, but no one has held the review and the approval steps are skipped for urgent work. Assessors use interviews with maintenance and security staff to confirm the written process, so a gap between the document and practice surfaces quickly. Compare the procedure with the last three real maintenance sessions and update whichever is wrong.

Maintenance paths found late

A vendor VPN, a remote desktop tool installed on a server or a modem on a controller was never added to the system inventory. Those paths often surface during an assessment, which means the organization cannot show approval or monitoring for them. Scan network boundaries for remote access services, compare findings with the configuration inventory, and bring every discovered path under the same approval and logging process before the assessment begins.

What buyers and practitioners ask about 03.07.05

Did 03.07.05 change from Rev. 2, and what does that mean for DoD work?

The change is minor in NIST's analysis, but your contract still decides which revision applies. NIST's Rev. 2 to Rev. 3 change analysis traces 03.07.05 to Rev. 2 requirement 3.7.5 and classifies the change as minor. CMMC Level 2 still uses Rev. 2, where the requirement is MA.L2-3.7.5 and carries 5 points under the 32 CFR 170.24 scoring methodology. Under 32 CFR 170.21, that item cannot go on a plan of action and milestones to reach Conditional status. A DoW class deviation signed on 3 September 2026 has contracting officers name Rev. 2 explicitly. A FAR overhaul proposed rule would move contractors to Rev. 3 with DoW-published ODP values, but it was not final as of October 2026. Ask your contracting officer which revision your contract cites and get the answer in writing.

What evidence will an assessor sample first for nonlocal maintenance?

Expect the assessor to ask for records of remote maintenance sessions and the procedures that govern them. SP 800-171A Rev. 3 lists examine objects for 03.07.05, including maintenance policy and procedures, remote access policy and procedures, procedures for nonlocal system maintenance, records of remote access and maintenance records. Interviews cover personnel with maintenance responsibilities, security staff and system administrators, who should explain how a session is approved, watched and closed. For testing, the assessor looks at the mechanisms themselves. Useful samples include identity provider logs showing the second factor used for each session, the approval or ticket for each session, and the time the connection ended. Platform audit trails help here. OpenBao audit devices record every API request and response, and Nextcloud's admin_audit app writes to audit.log. Confirm retention periods with your assessor before collection starts.

Does a VPN alone satisfy the nonlocal maintenance requirement?

No. A VPN can carry the session, but 03.07.05 asks for more than a tunnel. The organization must approve and monitor each nonlocal maintenance or diagnostic activity, use multi-factor authentication and replay resistance when the session is established, and end the session and network connections when the work is complete. A VPN that accepts only a password does not meet the multi-factor part. Check how the VPN authenticates maintainers, whether it accepts a second factor that resists replay, and whether it tears down the tunnel and any vendor path when the ticket closes. Many gaps sit outside the VPN, including standing vendor accounts, jump hosts left open and sessions that stay up overnight. Ask your assessor how they will test each of these before you finalize the design.

What does nonlocal maintenance control work cost and what drives it?

This control has no fixed price, so ask for a written scope before comparing numbers. Costs fall into four groups. Internal staff time covers approvals, session monitoring and evidence. Identity and access tooling covers the identity provider, the authenticators and any license your VPN or bastion host needs. Logging and retention covers storage and review of session records. External help, if you buy it, covers design, configuration, testing and evidence preparation under a fixed scope. An independent assessor is paid separately and is the only party that issues a report. Setup costs come from inventorying vendor paths and migrating accounts, while recurring costs come from monitoring, authenticator replacement and periodic reviews. Cost rises with the number of maintenance vendors, systems and existing access paths. Ask each bidder for line items in these groups, the assumptions behind them and what is excluded.

How long does this take and what does it need from our team?

The duration depends on how many maintenance paths you have and how many already use strong authentication, so ask for a timeline in the written scope. No duration is given here. Your team will need to supply an inventory of every nonlocal maintenance path, including vendor accounts, jump hosts and remote consoles. You also need an identity owner who can add second factors and decide which authenticators are accepted, a network owner who controls session termination, a logging owner who confirms records are kept, and maintenance staff who can be interviewed. Plan a change window, because moving maintainer access to stronger authentication can interrupt vendor work. Ask the partner to list every input they expect from your team before work starts.

Can our own staff implement nonlocal maintenance controls without outside help?

Yes, if your team has skills in identity, network access and logging. The organization owns its controls, so internal staff can design, configure and document them. The work that needs the most care is inventory and cutover: finding every vendor path, moving maintainers to strong authentication without breaking support, and proving that sessions end. Internal teams often run this alongside daily operations, which can stretch the schedule. Test each control yourself before the assessor arrives, and keep records that match the procedures you wrote. Note the boundary: only an independent assessor or certification body issues reports or certificates, so an internal review, however thorough, does not replace that step.

When should we bring in an implementation partner for this control?

Bring in a partner when the gaps are wide, the deadline is fixed or your internal team cannot spare the people. Common triggers include several maintenance vendors with separate accounts, no central identity provider, multi-factor authentication that does not cover maintenance paths and incomplete session logs. A partner's role is to prepare systems and evidence, not to judge compliance. DeployOpen plans, implements and hardens self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and prepares the configuration and evidence an assessor will test. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not issue audit reports, attestations or certifications, and your organization keeps ownership of its controls.

Can open-source identity tools provide the second factor this control needs?

Several open-source identity platforms can enforce a second factor, but whether a given factor is replay resistant is a question for your assessor and your configuration. The authentik authenticator validation stage checks enrolled second factors at login, including TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes. FreeIPA supports HOTP and TOTP tokens, including software tokens enrolled by QR code and hardware tokens such as YubiKeys, and it can proxy OTP checks to an existing RADIUS server during migration. Start by listing which factors each maintainer may use, then remove any factor your assessor will not accept for these sessions. Static recovery codes and SMS or email codes need extra scrutiny. Confirm the design against the 03.05 requirements before you build it.

How DeployOpen scopes and prepares 03.07.05 evidence

DeployOpen works on 03.07.05 Nonlocal maintenance as an implementation partner: we prepare the remote maintenance paths, authentication for those sessions and the logs that show them, while your organization owns the control and an independent assessor judges it. Engagements are fixed-scope, with ongoing support available as a retainer.

How we scope

Written scope names every system, maintenance path and vendor connection that carries nonlocal maintenance sessions.
We confirm which people may start nonlocal maintenance and who approves each session before work begins.
Scope records the ODP values your organization assigns for session and monitoring requirements, with your owner named for each.

How we build

We configure multi-factor, replay-resistant authentication for maintenance sessions, using the enrolled factors your identity platform supports.
We set session timeouts and connection termination so access ends when the maintenance activity is marked complete.
We enable logging of nonlocal maintenance sessions and protect those logs so reviewers can trace each approval and session.

How we hand over

Documentation maps each determination statement in SP 800-171A Rev. 3 for 03.07.05 to the configuration, procedure or record that answers it.
Handover covers the maintenance procedure, remote access procedure and session approval records your assessor will ask to examine.
Your staff receive a walkthrough of the session workflow, so administrators can run and show the control without us present.

How we support

Ongoing support is available as a retainer for changes to authentication, identity providers and maintenance access paths.
Retainers can cover periodic checks that session logs still record approvals, authentication and termination after upgrades.
We do not issue assessment reports or certifications; your independent assessor decides whether the evidence meets the requirement.