Self-hosted remote access for PCI DSS MFA requirements

Assessors ask for a current list of every account that can reach the cardholder data environment (CDE) remotely, with the business reason, the approver and the approval date for each. In a Guacamole deployment, the list is usually produced from the user, group and connection permission records in the database backend, which show which users can open which connections. Confirm with your QSA whether they want a point-in-time export, a quarterly review record, or both, and whether approvals must come from someone outside the requesting team. Also confirm how they will test that the list matches what the gateway actually enforces, since an export that differs from live permissions is a common finding.

The assessor will want evidence that every remote login into the CDE passes through MFA before a session opens, not just that MFA exists somewhere in the environment. For Guacamole, the relevant evidence comes from the authentication extension in use, such as the Duo or TOTP extension, or the SAML, OpenID Connect or smart card configuration that delegates MFA to an identity provider. Export the relevant configuration files with secrets removed, along with a test login transcript showing the MFA prompt. Confirm with your QSA how they want to see that the MFA factor cannot be bypassed by connecting directly to the target hosts, which is why network placement matters as much as the gateway settings.

Assessors look for one account per vendor person, not shared vendor logins, with a documented sponsor, the access window and a recorded removal date. Records should show when each account was created, what it was granted, when it was used and when access was revoked at contract end. Guacamole stores user and connection assignments in its database, and the audit and access logs show activity against those accounts. Confirm with your QSA how they will sample vendor accounts, whether they expect a reconciliation against contract or HR records, and how long removal evidence must be kept.

Assessors typically want to see that privileged or vendor sessions into the CDE are recorded, that recordings cannot be altered by the people being recorded, and that retention periods are defined and enforced. Guacamole's session recording player extension and its recording path settings produce these files, so export the recording configuration, the storage location and the access controls on that storage. Confirm with your QSA which sessions must be recorded, how long recordings must be kept under your own retention policy, and whether they will review a sample of recordings during the assessment.

Assessors expect logs covering successful and failed logins, MFA challenges, connection opens and closes, permission changes and administrative actions on the gateway, all sent to a central store that the gateway administrators cannot quietly edit. In a Guacamole stack, these come from the web application, the authentication extension, the database and the host or container running guacd, so each source needs to be identified and time synchronized. Confirm with your QSA which log fields they require, the retention period they expect, and whether they want evidence that logs are protected from modification and forwarded off the gateway in near real time.

Assessors look for evidence that a named person or automated process reviews remote access logs on a defined schedule and follows up on anomalies. The strongest evidence is a dated review record with the reviewer, the scope reviewed, the findings and the actions taken, supported by alert rules that flag failed MFA bursts or access outside approved windows. Your SIEM or log platform will hold these records, and the Guacamole logs are the input. Confirm with your QSA how often they expect reviews, whether automated alerting counts as review, and what sample of review records they will request.

The evidence trail depends on whether your assessment uses a Report on Compliance completed by a Qualified Security Assessor or a Self-Assessment Questionnaire with an Attestation of Compliance, and the QSA or your payment brand contacts will confirm which applies. In either case, prepare a map from each remote access requirement to the artifacts above, the owner of each artifact and where it is stored. Note that PCI DSS v4.0.1 is the only active version, and DeployOpen prepares systems, controls and evidence for assessments but does not issue reports, attestations or certifications. Confirm with your QSA or acquirer which template and evidence format they accept.

The biggest cost drivers are the number of entry points into the cardholder data environment, how many distinct user populations need access (employees, vendors, managed service providers), and how far the design must be documented and tested to satisfy a qualified assessor. Each of these changes the amount of identity integration, network placement, logging and evidence work. Other drivers include whether you run the gateway in your own data center or in a cloud account, whether session recording must be retained and searched, and how many internal reviews you need before the assessor sees the design. Ask any implementation partner to price these items separately so you can see which ones move the total.

It is both. The one-time work covers planning, building the gateway, integrating identity and MFA, configuring vendor access controls, setting up logging and session recording, and preparing the evidence for the assessment. The recurring work covers patching the gateway and its operating system, renewing certificates, reviewing vendor accounts, retaining and reviewing logs, testing backups, and re-checking the design when the PCI DSS version or your cardholder data environment changes. PCI DSS v4.0.1 is the only active version as of this writing, so confirm with your assessor which version applies to your next assessment. Ask for the recurring operating effort as its own line in any quote.

The pace is set less by the software installation than by decisions and approvals. Scoping which systems are in the cardholder data environment, agreeing the network placement of the gateway, deciding who may connect and under what approval, and getting the MFA provider and identity source connected usually take the longest. Session recording storage and retention rules, and the review process for vendor access, add further steps. Because DeployOpen works on fixed scope, the timeline is agreed in writing before work starts and tied to these named dependencies. Ask the partner to show which milestones depend on your staff and which depend on their own work.

Your staff must own several decisions that no implementer can make for you. These include the scope of the cardholder data environment, the list of systems that remote users may reach, the approval path for each vendor, the identity provider and MFA method, and the retention period for session recordings. You will also need network and firewall owners to open the agreed paths, a named security owner for access reviews, and people who can run the gateway after handover. Ask the partner to give you a written list of these inputs with an owner and a due date for each, before the engagement starts.

An in-house team can run the gateway if it has people with skills in Linux administration, network segmentation, identity integration, TLS and logging, and if it can keep patching and access reviews on schedule. The harder part is the first build and the evidence. Teams often underestimate the design review, the hardening baseline, the test of MFA on every path into the environment, and the documentation an assessor will request. Assess your team against those skills and against the recurring duties listed above. A partner can cover the gap for a fixed scope, and the handover should leave your team able to operate the gateway alone.

DeployOpen prepares systems, controls and evidence for compliance assessments, including the configuration records, access review samples, logging and session recording configuration, and test results that an assessor will ask for. DeployOpen does not issue audit reports, attestations or certifications. Only a Qualified Security Assessor or a valid self-assessment questionnaire with an Attestation of Compliance can state that your environment meets PCI DSS. Confirm with your assessor and your payment brand which evidence they will accept, and make sure the scope of the partner's evidence work is written into the fixed-scope agreement.

Ask for the quote to list each deliverable, the systems in scope, the assumptions about your environment, and the inputs you must supply with their owners. It should separate one-time build work from recurring support, state which PCI DSS version and assessment type it targets, and name the evidence package delivered at handover. Ask how changes to scope are priced and approved, what happens if an assessor requests additional evidence, and what the handover and training include. DeployOpen does not publish a price list and quotes follow from the written scope, so compare proposals on the same scope definition.

A browser gateway usually adds work at the start because each connection path must be designed, approved and recorded, but it can reduce the number of standing network paths that must be managed later. A VPN generally requires network-level access rules and client management for each vendor, which shifts effort toward firewall changes and endpoint support. The comparison depends on how many vendors connect, how often, and what their devices look like. Ask any partner to model both options against your vendor list and your assessor's expectations before you choose one.