Self-hosted remote desktop for the public sector

Why self-hosted remote desktop for the public sector starts with the control catalog

An agency IT or security lead who must let staff and contractors work remotely needs to decide two things before any product choice: which control catalog the system must meet and where the system is authorized to run. Apache Guacamole fits browser-based access behind agency identity, and RustDesk fits attended and unattended support on servers the agency runs itself. Both must sit inside the agency's authorized boundary, because a remote access gateway that brokers privileged sessions into federal systems is part of the security perimeter the agency has to assess.

NIST SP 800-53 Rev. 5 is the federal control catalog, and Release 5.2.0 of 27 August 2025 is the current release. The SP 800-53B baselines select 149 controls and enhancements at the low level, 287 at moderate and 370 at high, so the baseline a system falls under changes how many access, audit and encryption controls the gateway must document. Under FISMA, Inspectors General independently assess agency system security and report to OMB, which means the evidence for remote access will be reviewed by people outside the project team. Confirm the impact level and baseline with your authorizing official before you size the design.

FedRAMP scope is the other early decision. FedRAMP applies to cloud products and services that handle federal information on behalf of an agency, while systems used only for one agency's operations on cloud infrastructure and not offered as a shared service are out of scope under OMB M-24-15. A self-run gateway in agency-controlled infrastructure may therefore fall under the agency's own authorization rather than a FedRAMP package, but confirm that reading with your agency's authorizing official. DeployOpen prepares controls, configurations and evidence for that assessment, but it does not issue authorizations, attestations or certifications. Those come from the agency and its assessors.

Which federal and state requirements change the remote desktop design

This table maps each federal and state requirement that touches agency remote access to what it means for the gateway, session recording, identity and hosting. Read each row as a design question to settle before choosing a baseline, a hosting model or a login method, and confirm the applicable baseline with your authorizing official or compliance office.

Requirement	What it asks for	Design impact on the remote desktop gateway
NIST SP 800-53 Rev. 5 (Release 5.2.0, 27 August 2025)	Federal control catalog covering access control, audit, identification and system integrity. SP 800-53B selects low, moderate and high baselines with 149, 287 and 370 controls and enhancements respectively.	Choose the baseline first, because it sets how many access, audit and session controls the gateway must document. Confirm the baseline in the system security plan before selecting components.
FISMA and OMB Circular A-130	Agencies must protect systems in proportion to risk. Inspectors General independently assess agency system security and report to OMB.	Expect the gateway to be in scope of agency assessments. Keep configuration, access reviews and session logs in a form an Inspector General can sample.
CJIS Security Policy v6.1 (effective 26 June 2026)	Criminal justice information in transit and at rest outside physically secure locations needs FIPS 140-3 validated modules or AES with 256-bit keys. Vulnerability scanning is at least monthly.	If a remote session can display CJI, enforce TLS with validated cryptographic modules on the gateway and every hop. Schedule monthly scans of the gateway, guacd hosts and recording storage.
32 CFR 2002.14(h)(2) (CUI on non-federal systems)	Agencies must use NIST SP 800-171 when setting protections for CUI on non-federal information systems, unless the CUI authority prescribes other safeguards.	Contractor-operated gateways that touch CUI sessions inherit the 800-171 requirement set. Confirm which CUI categories a contractor's remote technicians can reach before setting session scope.
ADA Title II web accessibility (28 CFR 35.200)	State and local government web content and mobile apps, including contracted content, must meet WCAG 2.1 Level A and AA. The compliance date is 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts.	The login page, session launcher and any self-service portal in front of Guacamole are public-facing web content. Include them in accessibility testing and confirm which compliance date applies to your entity.
FedRAMP scope (OMB M-24-15)	Cloud products that create, collect, process, store or maintain federal information on behalf of an agency fall in scope. Systems used only for a single agency's operations on cloud infrastructure, not offered as a shared service, are out of scope.	A gateway run by a vendor or managed provider as a shared service may fall in FedRAMP scope. A gateway the agency runs alone in its own cloud account usually does not. Confirm the classification with the agency's FedRAMP or security office before choosing hosting.
Smart card and SAML identity (agency login standard)	Agencies generally require strong, phishing-resistant authentication for staff and contractors. Guacamole documents SAML and smart card single sign-on extensions.	Confirm whether PIV or CAC credentials must be accepted directly or through an identity provider. Test the chosen extension against the agency's certificate chain and revocation checks before go-live.
Session recording and audit evidence (NIST AU control family)	Audit records must cover who connected, to which system, when and what was done, and must be protected from alteration and retained as the agency schedule requires.	Use the session recording player extension in Guacamole where the manual supports it, store recordings on write-once or access-restricted storage, and confirm the retention period with the records officer.

How agency, contractor and criminal justice settings differ

In a direct agency deployment, the agency owns the data center, the identity provider and the remote access gateway. The boundary is the agency's own network perimeter, and the gateway sits in a segment that can reach internal hosts while staff reach it from managed endpoints or approved networks. Because no third party operates the platform, the agency's own security and infrastructure teams carry the controls for the gateway, its database and its recordings. The fit is strongest when the agency already runs its own directory and smart card infrastructure and wants Guacamole to sit behind that identity layer rather than create a parallel login.

Boundary: the gateway is placed in a dedicated segment between the user network and internal Windows, Linux or VNC hosts, with firewall rules that allow only the protocols and destinations listed in the design.
Operator: agency staff run the gateway, the guacd daemons and the authentication extensions, with DeployOpen only if the agency has contracted for planning, hardening or handover.
Recordings: session recordings are written to agency-controlled storage inside the same data center, with retention and access rules set by the agency's records policy.
Encryption: confirm with the agency's security office whether any CJI or other regulated data passes through the sessions, since that decides which FIPS 140-3 or AES-256 requirements apply.
Identity: smart card and SAML login are configured against the agency's existing identity provider, with MFA enforced on the gateway itself.

Before design starts, confirm which control catalog the agency's authorization uses and which data classes the gateway will touch.

Which platforms fit agency remote access and why

Agency remote access usually splits into two jobs: browser-based access to named systems for staff and contractors, and attended or unattended remote support for endpoints. The cards below separate those jobs, name the components each one brings, and list the checks that connect a platform choice to federal and state control requirements.

Apache Guacamole for browser access

Guacamole is a clientless gateway that publishes RDP, VNC and SSH hosts through an HTML5 browser, so contractors do not need a VPN client or an installed agent. It is licensed under Apache-2.0, and version 1.6.0 was released on June 22, 2025. Its extensions cover SAML and smart card single sign-on, OpenID Connect, and a session recording player. Confirm that the SAML or smart card extension meets your agency's authentication policy, and test the recording player against your retention rules before you commit to a design.

Guacamole gateway architecture and placement

The web application handles authentication and forwards the Guacamole protocol to guacd, which loads the protocol plugins that reach target hosts. For agency use, this split decides where the gateway sits, which network segment can reach guacd, and which hosts can be published at all. Document the placement in your boundary diagram, and confirm with your security team how guacd and the database backend are hardened and monitored.

RustDesk self-hosted server for support

RustDesk suits attended and unattended help desk sessions for endpoints, with the ID and rendezvous server (hbbs) and the relay server (hbbr) run inside agency infrastructure. The open-source server and client are licensed AGPL-3.0. Server Pro adds 2FA, an audit log, access control, OIDC and LDAP integration, and the pricing page states that Pro is not a SaaS subscription. Check whether the audit log and access controls meet your evidence needs before you rely on them.

Policy controls for RustDesk misuse

The RustDesk README states that its developers do not condone unauthorized access, control or invasion of privacy, and the client can be installed from several public channels. An agency must therefore govern which clients may run, who may connect to which endpoints, and how sessions are approved and logged. Define these rules in writing, block unapproved clients through endpoint management, and test that unattended access requires explicit enrollment.

Vendor and contractor access controls

Contractors and managed service providers need named accounts, approval steps, time-limited access and recording that can be reviewed later. Guacamole can enforce per-connection permissions and recording, while RustDesk Server Pro adds centralized settings and audit logs. Ask your partner how accounts are deprovisioned at contract end, and which evidence will show that a vendor session was approved, bounded and reviewed.

Confirm certification and FedRAMP status

A self-hosted open-source component is not itself FedRAMP authorized, and no vendor certification transfers automatically to your deployment. Where data is cloud-hosted or a service is offered to multiple agencies, FedRAMP scope rules may apply. For each component, ask the vendor or licensor for written evidence of any certification, and confirm with your authorizing official which control baseline and FIPS 140-3 modules your environment must use.

How an agency rollout moves from authorization scope to handover

The sequence turns an agency's authorization boundary into a tested Guacamole gateway, a logged and recorded access path for staff and contractors, and a handover package that lets an assessor trace each control to evidence. Each phase closes with a named output so the next phase starts from agreed facts.

Define scope and boundary with the authorizing official
The agency's system owner, security office and the authorizing official agree which systems, user populations and contractor roles fall inside the remote access boundary, and which systems stay out. DeployOpen maps that boundary against the control baseline the agency already uses, such as the NIST SP 800-53 baseline selected for the system, and confirms whether any hosted component falls under FedRAMP scope. The output is a signed scope statement, a data flow diagram for remote sessions, and a list of the controls the gateway must support. The phase is done when the authorizing official accepts the boundary in writing.
Integrate smart card and SAML identity
The identity team and DeployOpen connect Guacamole to the agency's identity provider using the SAML and smart card single sign-on extensions, and confirm how the gateway reads group membership for connection permissions. Test accounts cover staff on agency-issued credentials, contractors with separate identities, and at least one failed-login path. Each test case is recorded with the expected result, the observed result and the log entry produced. The phase closes when every test case passes and the identity mapping is documented for the assessor.
Build and harden the gateway
DeployOpen builds the Guacamole web application, guacd and the database backend inside the agency's approved network zone, placing the entry point where the agency's architecture requires. The build applies the agency's hardening baseline to the host, containers, TLS configuration, database access and service accounts, and keeps guacd reachable only from the web tier. The team runs configuration checks and a targeted security test of the gateway before any user reaches it. The output is a hardened build record, a configuration baseline under change control, and a test report with open findings and owners.
Stand up the recording and log pipeline
The team enables Guacamole's session recording and configures where recordings and connection logs are written, how long they are kept, and who can review them. Logs from the gateway, identity provider and database are forwarded to the agency's central log platform, with time synchronization checked across all sources. The team runs a controlled session, then confirms that the recording plays back, the log entries link to the correct user and target host, and access to the recording store is restricted to named reviewers. The output is a tested pipeline and a retention and review procedure approved by the agency.
Pilot with named contractors and staff
A limited group of named agency staff and contractors use the gateway for agreed tasks, such as reaching specific maintenance hosts under time-limited approvals. The pilot tests connection permissions, session approval steps, recording behavior and the help desk process for lockouts and certificate issues. Findings are logged with severity and an owner, and the agency decides which fixes are required before wider use. The output is a pilot report that lists accepted user populations, unresolved risks and the criteria for expanding access.
Retire unmanaged remote support tools
The agency inventories remote support and remote monitoring applications already in use across its endpoints and vendor relationships, then compares each one against the approved gateway path. Unapproved tools are blocked or removed through the agency's endpoint management, and vendors are told in writing which access path replaces their old one. The team checks that each retired tool no longer connects to agency systems and that exceptions are recorded with an owner and an end date. The output is a retirement register showing each tool, its replacement and the evidence that it was removed.
Hand over with an evidence binder
DeployOpen assembles the handover package: the scope statement, architecture and data flow diagrams, identity test results, hardening records, recording and log configuration, pilot report, retirement register and the runbooks for operations and incident response. Each control in the agreed baseline is mapped to the artifact that shows it operating, so the agency's assessors can trace evidence without asking for reconstruction. The agency's operations team runs a supervised change and recovery exercise before taking ownership. DeployOpen prepares this evidence for the agency's assessment process but does not issue audit findings or certifications, which remain the role of the agency's assessors and authorizing officials.

How to retire unmanaged remote support apps without stopping support

Agency endpoints often carry consumer remote tools that help desks installed to fix problems quickly, and nobody recorded them as sanctioned software. Those tools typically reach a vendor cloud, use accounts outside agency identity, and leave no session trail the agency controls. The first step is inventory: run a software and service discovery pass against every managed endpoint and server, and look for known remote access executables, background services, scheduled tasks, and outbound connections to vendor relay hosts. Ask your endpoint management team to confirm which discovery sources they can query and what they cannot see, such as unmanaged personal devices or contractor laptops. Then decide which tools are blocked outright, which are allowed until a cutover date, and who approves any exception. CISA publishes guidance on remote access and remote monitoring and management tools; read the current text directly on the CISA website before writing your blocking policy, because the recommendations are updated and this summary is general.

RustDesk can replace the help desk use case on infrastructure the agency runs. Its open-source server builds two services, hbbs for ID and rendezvous and hbbr for relay, so the ID and relay endpoints can sit in the agency network rather than on a vendor cloud. For audit trails, centralized settings, two-factor authentication and LDAP or OIDC sign-on, the decision is whether the Server Pro features justify its licensing. The open-source server does not provide that console, so confirm the feature set against the current RustDesk pricing page before you commit. Also confirm the client build distribution path, since the client is distributed through several channels and only approved builds should reach endpoints. Keep in mind that the RustDesk README includes a misuse disclaimer, which does not replace your own acceptable use rules.

Stage the migration so tickets keep flowing. Start with a pilot group of help desk technicians and a small set of managed endpoints, and run RustDesk alongside the existing tool for a defined period. Only after technicians complete their normal ticket types on the new path should you block the old tool for that group. Move in waves by business unit, and keep a rollback route to the old tool until the wave's tickets close without escalation. Hold the blocking change for the old tools until the inventory shows nothing still depends on them. Record each wave's cutover date, approver and exceptions so the change log supports later review. Ask any implementation partner to define the wave plan, rollback criteria and the help desk runbook changes in the written scope before work starts.

What auditors and inspectors ask for and which component produces it

This table maps the evidence public sector assessors typically request for remote access to the component that produces it, with the control family it supports. Read it as a starting point for the evidence package, then confirm each item with the agency's assessor or inspector before build.

Evidence item	Control family	Producing component	What to confirm with the assessor
Access logs for every remote session start, end and failed attempt	Audit and accountability (AU)	Guacamole audit logging through its database or log backend, forwarded to the SIEM	Which log fields (user, target host, source address, timestamp) they require and the retention period their authorization sets
MFA and smart card login records	Identification and authentication (IA)	Guacamole smart card or SAML extension logs, with the identity provider as the source of record	Whether they accept IdP logs as primary evidence or need gateway-side records as well
Session recordings and retention	Audit and accountability (AU), media protection	Guacamole session recording player extension, with recordings written to controlled storage	Who may view recordings, how long they are kept, and how recordings are protected from alteration
Connection permission reviews	Access control (AC)	Guacamole connection permissions exported on a schedule, reviewed against the identity directory	Review frequency, reviewer role, and how removed or contractor accounts are shown as closed
Vulnerability scan results for the gateway and relay hosts	Risk assessment (RA), system and information integrity (SI)	Scanning tool run against the gateway, guacd and any RustDesk relay hosts, with results filed in the SIEM or ticketing system	Scan frequency, scope and remediation timelines, including whether monthly scanning applies to their data classification
Change records for gateway configuration and connection definitions	Configuration management (CM)	Change tickets in the ITSM system linked to version-controlled configuration of Guacamole and any RustDesk Server Pro settings	Which changes need approval, and whether emergency changes require after-the-fact review
RustDesk audit log for attended and unattended support sessions	Audit and accountability (AU)	RustDesk Server Pro audit log, if the tool is used for IT support, forwarded to the SIEM	Whether an unlicensed open-source RustDesk server can meet the same logging expectation, or whether Pro is needed
System security plan describing the remote access boundary	Planning (PL), system boundary documentation	Architecture document and data flow diagrams maintained by the implementation team and the agency	Whether the plan must name the gateway as a separate component, and which baseline (low, moderate or high) applies

Integration points that agency reviewers check first

Agency reviewers usually start with the systems the gateway must trust, log to and sit beside. Each integration point below changes who can reach a host, what evidence exists afterward, and where the components can run inside government infrastructure.

Agency identity provider and smart card trust

Guacamole can authenticate users through SAML, OpenID Connect, LDAP or Active Directory extensions, and its manual documents smart card single sign-on. Reviewers will ask which certificate authority anchors the smart card trust, how revocation is checked, and whether the gateway accepts only assertions from the agency identity provider. Confirm which extension your agency has approved and test the revocation path before go-live, not after.

SIEM and log forwarding

Gateway authentication events, connection starts and session activity need to reach the agency SIEM in a form analysts can query. Check whether the Guacamole logs, the database audit trail and the reverse proxy logs are all forwarded, that timestamps come from a common time source, and that log transport is encrypted. Ask who owns alert rules for failed smart card logins and off-hours sessions.

Network placement and DMZ conduits

The gateway sits between a restricted user zone and the target enclave, so its placement defines the conduits a reviewer must approve. Document which ports open from the user side to the web application, which open from guacd to target hosts, and which management paths exist. Each conduit should have a named owner, a documented purpose and a rule that denies everything else.

Recording storage and retention

Session recordings are sensitive records in their own right, and their storage location, access list and retention period must be set by the agency's records schedule rather than by default settings. Confirm where recordings are written, who can replay them, how they are protected at rest, and how deletion is logged. Ask the implementation partner to show the retention job and its evidence before handover.

Database backend choice

Guacamole stores connection definitions, users and permissions in MariaDB or MySQL, PostgreSQL or SQL Server, as documented in its manual. The choice should follow the agency's approved database platform, backup standard and support contract. Check encryption of database connections, separate credentials for the application and for administrators, and tested restore procedures that include the permission model.

RustDesk client distribution rules

RustDesk clients are published through GitHub releases, F-Droid and Flathub, which many agencies do not allow on managed endpoints. Establish an internal build or mirror of approved client versions, a software approval record for each release, and a rule for deploying the client through the agency's endpoint management tool. Confirm that the self-hosted rendezvous and relay servers are the only ones the approved client is configured to use.

What agencies ask before hiring a partner for remote desktop

Does self-hosted remote desktop for an agency need FedRAMP authorization?

Not automatically. FedRAMP's scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. A Guacamole gateway that runs on agency-controlled infrastructure and is used only for that agency's own operations sits outside that scope. The question changes if the design uses a hosted or shared service that handles federal information. Confirm the hosting model with your authorizing official and your FedRAMP program office before scoping the work, and document the answer in the system boundary.

What drives the cost of a public sector remote access engagement?

Cost follows the written scope. The main drivers are the number of protocols and target systems, how many identity sources must integrate (smart card, SAML, directory services), the number of network zones and gateway instances, the depth of hardening and evidence collection, and how long the agency needs recording storage and support. One-time work covers design, build, integration and testing. Recurring costs cover infrastructure, patching, certificate renewal, log retention and any support retainer. Ask each bidder for a quote that separates these items and states what the agency must provide.

How long does assessment preparation take for a remote desktop system?

The duration depends on how many controls the agency must evidence, how much of the design already exists, and how quickly the assessor and internal teams can review artifacts. Preparation usually takes longer when identity, logging and network boundary decisions are still open. DeployOpen does not publish timelines before scope is agreed, so ask for a phased plan with dependencies listed, and confirm assessor availability with your authorizing body before setting dates.

What must the agency provide before a partner starts the work?

A partner needs named decision-makers, access to the identity provider and certificate authority, network placement rules, a list of target systems with protocols and owners, and the agency's control baseline or internal policy set. The agency should also supply its change process, log destinations, backup standards and the approved list of vendor accounts. Missing inputs are the most common cause of schedule slips, so confirm them in the statement of work and assign an agency owner to each item.

Can our internal staff operate the platform after handover?

Yes, if the handover is planned for it. Internal staff need working knowledge of the Guacamole web application, the guacd daemon, the authentication extension in use, the database backend and the session recording setup. Ask the partner for runbooks, a restore test, a patching procedure, and training sessions tied to the agency's operating model. Decide up front whether internal staff will handle routine work and whether a retainer covers upgrades and out-of-hours incidents.

How does WCAG 2.1 apply to a remote access portal?

Under the ADA Title II rule, state and local government web content and mobile apps, including content provided through contracts or licenses, must meet WCAG 2.1 Level A and AA. The rule sets 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts (28 CFR 35.200). A Guacamole login and launcher page is web content, so the agency should include it in its accessibility review. Ask the partner which templates and custom pages it will change and how it will test them.

Do we need RustDesk Server Pro licenses for agency support?

Only if the agency chooses the Pro edition. The open-source RustDesk server, which runs hbbs and hbbr, is licensed under AGPL-3.0. RustDesk Server Pro adds features such as two-factor authentication, a web console, audit logs, access control and LDAP or OIDC integration. According to RustDesk's pricing page, Pro plans are billed annually, are not a SaaS subscription and are priced per login user and managed device. Confirm the feature set your audit and identity requirements need, and check current pricing directly with the vendor.

How does DeployOpen structure a public sector engagement?

DeployOpen works under fixed-scope engagements. Scope, deliverables and timelines are agreed in writing before work begins, and a quote follows from that written scope. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the agency's own infrastructure. It prepares systems, controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications. Ongoing support, upgrades and continuous testing are available as retainers. Ask for the written scope, the evidence list and the exit terms before signing.

What to ask an implementation partner before signing

Start with the authorization boundary. Ask the partner to draw the boundary that will hold the Guacamole web application, guacd, the database backend, the recording store and the identity provider, and to state which of those components sit inside the system security plan you will be assessed against. Ask who writes the boundary diagram, who signs off on it, and how it changes when a new protocol, a new agency or a new contractor enclave is added. If the partner cannot name the components or the data flows between them, the later control mapping will not hold up. Next, ask for the smart card and SAML test plan in writing before any build starts. Each login path should have named test cases: a PIV or CAC credential presented to the gateway, a SAML assertion from the agency identity provider, a contractor account from a separate issuer, a revoked credential, an expired certificate, and a failed second factor. Ask which Guacamole extension versions the partner will test against, which ones the agency has approved, and where the test evidence will be stored. Confirm also how the partner handles the Guacamole extension for smart card single sign-on and whether the agency's own identity team will run the final acceptance tests.

Ask how session recordings are encrypted at rest, who holds the keys, where the recordings are stored and how long they are kept. The answer should reference the retention period set by your records schedule and your audit control baseline, not the partner's default. Ask for the hardening baseline the partner will apply to the gateway, the database and the recording host, and ask which SP 800-53 control families it maps to, such as access control, audit and accountability, configuration management and system and communications protection. Request the control IDs in a spreadsheet or OSCAL-style mapping you can keep, rather than a summary slide. For cryptography, ask whether the modules that protect CJI in transit and at rest are FIPS 140-3 validated, and ask for the module certificate numbers and the exact versions in use. Confirm whether the partner has checked the CJIS Security Policy version that applies to your agency and its requirements for AES key length. Ask for the vulnerability scanning cadence on every component in the stack, including the monthly minimum described in the CJIS policy, and who triages findings. Finally, settle who holds privileged administrator access to the gateway and the hosts: named individuals, separate admin accounts, break-glass procedures, and whether the partner's engineers keep any standing access after handover. Require the handover package in writing, including runbooks, configuration exports, test results, recording samples and the evidence list, and confirm which parts an independent assessor will need to see.

How DeployOpen scopes and supports agency remote desktop work

DeployOpen plans, implements, hardens, documents and supports self-hosted remote access inside the agency's own infrastructure, whether in a government data center, a cloud account the agency controls or a disconnected network. We agree scope, deliverables and timelines in writing before work starts, and we prepare the controls and evidence that an agency's own assessors review.

How we scope

Confirm which user groups, agency networks and internal systems the gateway must reach before any design work starts.
Map the identity source, smart card or SAML login path, and the MFA method each user population will use.
Record the agency's applicable control baseline and the evidence its assessors will request, so both are in the written scope.
Engagements are fixed-scope, with deliverables and timelines agreed in writing. Ongoing support is available as a retainer.

How we build

Deploy Apache Guacamole and guacd in the network zones the agency designates, with the gateway placed in a controlled entry point.
Configure smart card or SAML single sign-on, connection permissions per role, and session recording storage with retention set by policy.
Test authentication, permission boundaries, session recording and logging against the agreed scope before anything goes live.

How we hand over

Deliver architecture records, configuration documentation and a control mapping that shows which evidence supports each requirement.
Walk the agency's operators through account onboarding, vendor access approval, session review and offboarding procedures.
Document backup, restore and upgrade steps so the agency's own staff can run the platform after handover.

How we support

Offer retainers for patching, upgrades, monitoring review and periodic security testing of the gateway and its integrations.
Review changes to identity providers, network paths and connected systems to keep the access design aligned with the agency's policy.
Support evidence collection for internal audits and external assessments, while the agency's auditors issue all findings and opinions.