Why remote access and VPN testing is a separate test
A security or compliance lead commissions VPN and remote access testing when a framework, a customer security review, an insurer or a product launch asks for evidence that the internet-facing door into the network has been checked. Remote access testing is a separate test because VPN concentrators, remote desktop gateways and zero trust access tools sit on the internet edge, hold the authentication step for everyone who connects, and grant internal reach once a session is established. A weakness in any one of those roles can give an outsider a route inside that a general external scan will not describe. The single most useful question to answer before scoping is which systems a successful remote session can actually reach.
The risk categories are specific. Management interfaces for appliances are sometimes exposed to the internet when they should only be reachable from an administration network, and the test should confirm which ports and portals answer from outside. Authentication needs its own review: the test checks whether MFA is enforced for every access path, including legacy protocols, fallback methods, service accounts and any gateway that accepts a second-factor bypass. Patch level matters because remote access appliances are a frequent target of published vulnerabilities, so the tester should compare firmware and software versions against vendor advisories rather than assume a recent update. Confirm with each vendor which versions and advisories apply to your model.
The external and internal test definitions already in use show where this work belongs. PCI DSS requirement 11.4.1 treats the exposed external perimeter as its own test scope, and CIS Safeguards 18.2 and 18.5 ask for annual external and internal penetration tests, so a VPN gateway usually falls within the external test. The part that sits inside the network, what a connected device or user account can reach after login, belongs to the internal test. Ask your provider to state in writing whether remote access is covered by the external test, the internal test or both, and whether the tester will validate reach from a standard remote user account. Testing is conducted within the agreed rules of engagement, as described in NIST SP 800-115.
What can be in scope for a remote access test
A remote access test covers more than the VPN box on the internet edge. The components below form one path from an internet address to an internal network, and each one can change what a tester is allowed to reach. Agree each item in writing before testing starts, so the scope, access and rules of engagement match what the business actually depends on.
VPN concentrators and gateways
These are the public-facing appliances that terminate remote sessions, usually with TLS or IPsec tunnels and a login portal. Confirm the exact make, model, firmware or software version and every public address or hostname that answers, including management interfaces, legacy portals and split-tunnel settings. Ask whether the tester may probe authentication pages, session handling and version exposure, and whether any device is hosted by a third party whose permission is also needed.
Remote desktop gateways
Remote desktop gateways broker sessions from the internet to internal Windows hosts, so they sit close to privileged systems. Agree which gateway endpoints, farms and brokered target hosts are in scope, and whether testing stops at the gateway or continues to the desktops behind it. Record which account types may log in through the gateway, since a weak gateway often matters because of the hosts it reaches.
Zero trust access brokers and proxies
Zero trust access tools publish named applications through identity-aware proxies or agents rather than opening a network tunnel. Scope the broker tenant, connector hosts, publishing rules and device posture checks as separate items. Confirm which applications are published, which policies decide access, and whether a connector runs inside the network, because that connector is often the bridge a tester most needs to examine.
MFA and identity providers
Remote access is only as strong as the sign-in in front of it. Identify the identity provider, MFA methods (such as push, one-time codes, hardware keys or SMS), fallback and recovery paths, and any federation to on-premises directories. Decide whether the tester may attempt password spraying or MFA fatigue checks against test accounts, and how lockout thresholds will be respected. Hybrid identity links to the sibling assessment on Microsoft Entra ID.
User roles and test accounts
Access results depend on who is logging in. Agree which roles are in scope, such as standard staff, contractors, administrators and service accounts, and provide dedicated test accounts with known group memberships. Confirm whether privileged accounts may be used, how credentials are issued and revoked, and who can see them. Keep a record of each account, its owner and the end date so the test leaves no unmanaged access behind.
Internal reach from a connected device
A connected device shows what remote access grants once inside. Decide whether testing stops at the tunnel, or whether the tester uses an enrolled laptop or a provisioned device to examine reachable subnets, shared drives, internal applications and management ports. Define the permitted internal targets, the allowed actions and the points where testing must halt, such as cardholder or safety systems. Confirm how segmentation between remote users and sensitive networks will be checked.
Rules of engagement
Written rules of engagement turn these decisions into a single agreement. NIST SP 800-115 describes a planning phase in which rules are identified and management approval is documented, and it provides a rules of engagement template in Appendix B. Use that structure to record in-scope addresses, testing windows, prohibited techniques, emergency contacts, data handling and the named approvers. Ask the provider to confirm which template fields it fills in and how changes to scope are approved during the test.
How a remote access engagement runs, phase by phase
The sequence moves from agreed rules and an inventory of exposed remote access services to validated findings and a retest, so the client ends with evidence of what an internet or remote attacker could reach and what was fixed. Each phase closes with a defined output that the next phase depends on.
Agree rules of engagement and management approval
DeployOpen and the client document the rules of engagement before any packet is sent, following the planning phase in NIST SP 800-115, which includes a rules of engagement template in Appendix B. The document names the VPN concentrators, remote desktop gateways and zero trust access tools in scope, the source addresses the testers will use, permitted and forbidden techniques, accounts supplied for authenticated testing, emergency contacts, and who signs for management approval. The step is done when the signed rules of engagement are on file and the named contacts have confirmed they can be reached during testing. Any timeline is set in the written scope.
Inventory remote access services and their exposure
Testers perform target identification and analysis, starting with review of the client's asset records, DNS entries, and firewall rules, then confirming with network discovery and port and service identification which remote access endpoints answer from the internet. The inventory records each product, its version as far as it can be determined from banners or responses, and whether it is reachable from outside the network or only from partner or branch ranges. Vulnerability scanning is used to flag known weaknesses, and every result is checked by hand before it goes into the working list. The step closes with an agreed inventory that the client has confirmed against its own records, since gaps between the two are often the most useful finding.
Test authentication, MFA and session handling
Testers move to target vulnerability validation, examining how each gateway authenticates users. The work covers password policy and lockout behavior, whether MFA is enforced on every entry path (including legacy protocols and fallback methods), how MFA enrollment and reset are protected, how sessions are issued, timed out and revoked, and whether certificate and single sign-on configuration can be bypassed. Credential testing is limited to the accounts and attempt rates set in the rules of engagement. The step is complete when each authentication path has a recorded result, a pass or a documented weakness, with the evidence needed for the report.
Validate patch level and known weaknesses
Where the rules allow, testers confirm whether the installed firmware or software build carries published fixes for the weaknesses identified in the inventory. Version identification from banners is treated as a lead, not as proof, so testers confirm the build through safe checks the vendor documents or through the client's own patch records. Each confirmed weakness is validated to the point where its impact is clear, without running public exploit code against production gateways unless the rules of engagement explicitly permit it. The step ends with a list of confirmed and unconfirmed weaknesses, each labeled with how it was verified.
Map what a connected device can reach
This is the phase that separates a remote access test from a perimeter scan. Using accounts that represent different user roles, testers connect through the gateway and record which internal address ranges, applications, file shares, management interfaces and directory services the session can reach. They check whether a standard user session can see administrative systems, whether segmentation rules hold for remote users, and whether a compromised remote endpoint could move toward cardholder or other critical systems. Testers stop at the point the rules of engagement set and document the reachable paths rather than traversing them further. The step is complete when the reachability map has been reviewed with the client's network team.
Report findings with evidence and remediation
DeployOpen writes the report in the phases defined by NIST SP 800-115, with each finding stating the affected gateway, the weakness category, how it was validated, the reachable impact, and a prioritized fix. Findings are rated against the client's own risk method, and where the client needs it, mapped to the relevant control text for its compliance framework without quoting copyrighted standards. The report separates confirmed issues from items that need client confirmation, so the client's auditor can see what was tested and how. The step closes when the client has accepted the draft and the findings are assigned to owners.
Retest fixes and close the engagement
After the client applies remediation, testers repeat the checks for each finding in the retest scope agreed in writing, confirming whether the weakness is closed, partly closed, or still present. Retesting is usually limited to the original findings unless the client requests a wider check, and any additional work is added to the written scope. The retest report records the date of each check, the evidence used, and the status of each finding, so it can be given to the client's auditor or customer. The engagement closes when the retest report is issued and any open items have agreed owners and dates.
Which weakness categories a remote access test looks for
This table lists the weakness categories a remote access test examines, how each one tends to appear on VPN concentrators, remote desktop gateways and zero trust access tools, and why it matters to the business. Read each row as a question to ask your provider about scope, and as a control to confirm in your own environment before the test starts.
| Category | What it looks like in this target | Why it matters |
|---|---|---|
| Exposed management or admin interfaces | Appliance administration pages, SSH or web consoles, or gateway management APIs reachable from the internet or from user subnets instead of a dedicated management network | Administrative access to the remote access platform gives an attacker control over every session it brokers, so exposure here usually outweighs a flaw in a single user path |
| Outdated firmware and patch level | Concentrator, gateway or agent versions that lag the vendor's current release, or hardening settings that were never reviewed after an upgrade | Known weaknesses in edge appliances are a common entry point, and testers need the exact version and patch state to judge exposure accurately |
| Authentication and MFA weaknesses | Fallback sign-in methods that skip the second factor, weak enrollment steps for new devices, or legacy protocols still accepted alongside modern ones | A strong primary password means little if a fallback path or old protocol lets a user connect without the second factor that the policy promises |
| Weak session and certificate handling | Session lifetimes that are too long, tokens that persist after sign-out or device change, certificate validation disabled on clients, or expired and self-signed certificates in use | Stolen or reused sessions let an attacker keep access after the legitimate user has left, and weak certificate checks make connections easier to intercept |
| Overly broad access policies | Remote users or devices placed in a flat network segment, split-tunnel rules that bypass inspection, or group policies that grant access to the whole internal range | A connected device should reach only the systems its role needs, so broad policies can turn a single compromised laptop into a path to critical or cardholder systems |
| Weak device posture checks | Access granted without verifying that the endpoint is managed, patched, encrypted or running current security software | Posture checks are the main reason zero trust tools differ from plain VPN access, and a missing or bypassable check weakens every session that depends on it |
| Missing monitoring of remote sessions | No alerting on impossible travel, repeated failed sign-ins, new device enrollments, or unusual data volumes through the gateway, and logs that are not forwarded to a central system | Without session monitoring, a misuse or intrusion through remote access may go unnoticed, and assessors often ask for evidence that logging and alerting work |
What a connected device can reach once inside
A VPN or gateway is only as safe as the network it opens onto. Hardening the concentrator, enforcing multi-factor authentication and patching the appliance do not answer the question that matters after a remote user connects: what can that session reach? A test of remote access should therefore include a representative connected device, such as a standard managed laptop joined with the same VPN profile and group membership a real user receives, and it should record every subnet, host, port and service that device can contact. The goal is to compare that reach against the access the business intended, not to prove that a connected device can reach anything at all. Confirm the device profile, the user groups, the split tunneling setting and the routing and firewall policy on the gateway with the client before testing begins, because these determine the starting position of the test.
Segmentation is the central check. Where the environment holds cardholder data, PCI DSS requirement 11.4.5 calls for penetration testing of segmentation controls at least every 12 months and after changes, to confirm that segmentation isolates the cardholder data environment from out-of-scope systems. Remote access paths are a frequent gap in that isolation because a single VPN group, a flat address pool or an overly broad firewall rule can connect remote users straight to the cardholder data environment. Ask the tester to state which segments the remote pool can reach and why, and to confirm whether a service provider's six-month cadence under requirement 11.4.6 applies to the same paths. Where remote administration is in use, compare reach against Microsoft's enterprise access model, which asks that a lower plane never be able to control a higher one. A remote administration path that lands on domain controllers, identity infrastructure or other Tier 0 assets is a finding regardless of how strong the login is, and it should be reported as a control plane exposure.
What drives the cost and duration of remote access testing
This table compares the factors that change the effort of a remote access test, from gateway count to retest scope, and shows who is paid for each part. Use it to see which parts of your environment widen the scope, then ask each provider to price those factors separately in the written quote. No price list exists, so a quote follows from the agreed scope.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of gateways and vendors | Each VPN concentrator, remote desktop gateway or zero trust broker has its own login flow, configuration and patch state to examine, and each vendor adds platform-specific checks. | Limit the first test to production gateways in use, and list any retired or lab appliances as out of scope in writing. |
| User roles and authentication paths | Contractors, administrators, vendors and standard staff may reach different resources through different sign-in methods, and each path needs its own validation. | Group roles with similar access and state which paths carry privileged or third-party access. |
| MFA and identity integrations | Testing MFA enrollment, fallback methods, certificate-based sign-in and links to the identity provider adds work beyond the gateway itself. | Confirm which identity systems are in scope and whether they are tested as part of a separate identity assessment. |
| Depth of internal reach testing | Checking what a connected device can reach once inside requires test accounts, segmentation checks and sometimes a foothold, which is more work than an exposure review alone. | Set a clear stopping point, such as reaching a defined set of segments, and agree how access is provided and monitored. |
| Environments tested | Production, staging and cloud-hosted gateways differ in configuration and risk, and each one tested adds planning, access and reporting time. | Test the production configuration where possible and sample staging only if it is built from the same images. |
| Retest scope | A retest of findings is usually priced separately from the first test and depends on how many items need validation and whether fixes change the gateway. | Ask for a retest included in the quote or priced per finding, and agree a window for fixes before the retest begins. |
| Reporting package | An executive summary, technical findings, evidence for an auditor or customer, and a remediation tracker each add writing and review time. | Ask the provider which report sections are standard and which are optional, and whether a compliance mapping is included. |
What you receive and whether it satisfies an auditor or customer
A remote access test produces a package of documents, and each part answers a different question from an assessor or customer reviewer. The cards below describe what is delivered, what it does not prove, and what to settle with the assessor before testing starts so the package is accepted without rework.
Executive summary and scope
The executive summary states what was tested, the overall exposure of the VPN concentrators, remote desktop gateways and zero trust access tools, and the most serious paths found. The scope section lists every appliance, gateway, hostname or IP range, the test accounts used and the dates of testing. Reviewers check this section first against their own asset inventory. Confirm before testing that the listed remote access endpoints match what the assessor expects to see in scope.
Method and rules of engagement
This section explains the approach, including whether testing was external or internal, authenticated or unauthenticated, and which phases were used. NIST SP 800-115 describes planning, discovery, attack and reporting, and its rules of engagement template is a useful reference for documenting authorization and limits. A reviewer will look for signed rules of engagement that match the work described here.
Findings with severity and evidence
Each finding names the affected appliance or gateway, the weakness category (for example, weak MFA enforcement, exposed management interfaces, outdated firmware or a session handling flaw), a severity rating with the basis for it, and evidence sufficient for the client to reproduce the check. Ask how severity is calculated and whether the client can review evidence without it exposing live credentials. Findings that depend on a specific configuration should say so.
Reachability from inside the network
For remote access, the key finding is often what a connected device can reach once authenticated. The report should map which internal networks, segments, admin interfaces or cardholder systems an authenticated remote session could contact, and whether segmentation held. Ask the assessor whether this mapping is needed for their review, because it supports segmentation claims under PCI DSS requirement 11.4.5.
Remediation guidance and retest results
Remediation guidance should be specific enough for a platform team to act on, such as the firmware version to apply, the MFA policy to enforce or the access rule to narrow. After the client fixes issues, a retest confirms each finding is closed or documents what remains open with a reason. Ask whether retest is included in the fixed scope and how long the retest window stays open, since assessors usually want the closed status recorded.
Attestation letter and assessor fit
The letter confirms that a penetration test was performed on stated dates by a named tester organization, against an agreed scope. It is evidence that testing happened, not an audit opinion, certification or statement that the environment is compliant. PCI DSS allows a qualified internal resource or a qualified external third party with organizational independence to perform the test, and the QSA or customer decides whether the package is sufficient. Confirm the required letter wording and acceptance criteria with the assessor before testing.
How remote access testing differs by platform
VPN concentrators and firewalls with SSL or IPsec termination are internet-facing by design, so they are usually the first item an external test reaches. Testing focuses on what the gateway exposes before authentication, how it validates sessions and certificates, and whether a connected client receives more network reach than its role requires. Weakness areas tend to cluster around management interfaces left reachable from the internet, legacy protocol or cipher options, session and timeout handling, and firmware that lags behind vendor advisories. Authentication is often delegated to RADIUS, LDAP or a SAML provider, so the gateway's configuration of that link matters as much as the gateway itself.
- Exposed management and admin interfaces: whether administrative portals or SSH are reachable from public networks or from user subnets.
- Authentication configuration: how MFA is enforced, whether fallback methods bypass it, and how the gateway handles failed and locked accounts.
- Patch and firmware level: the installed version compared with the vendor's published advisories, confirmed against the device itself.
- Split tunneling and routing: which subnets a connected client can reach, and whether tunnel routes match the documented access policy.
- Logging and session records: whether sign-ins, failures and policy changes reach a central log store.
Before testing, confirm with the vendor the supported firmware branch, the admin interface model and any testing restrictions in the support agreement, and confirm in your environment which firewall policies govern tunnel traffic.
Remote desktop gateways broker sessions to internal Windows hosts and usually rely on Active Directory for user identity, group membership and policy. Testing these gateways covers the outer edge, the session broker and the hosts behind it, and it has to account for the fact that a valid remote session often inherits the trust of an internal domain account. Weakness areas include overly broad access groups, weak or missing MFA on the gateway, sessions that persist after a user is disabled, and gateways placed in the same tier as the domain controllers they depend on. Findings here often connect to the Active Directory tier model, so the test should check how privileged accounts are allowed to sign in remotely.
- Group-based access: whether the groups that grant gateway access are narrow, reviewed and free of standing administrators.
- Privileged sign-in paths: whether Tier 0 or privileged accounts can open sessions from the gateway to lower-tier hosts.
- Session controls: idle timeouts, reconnection rules, clipboard and drive redirection, and recording settings.
- Gateway placement and trust: whether the gateway sits in a segment that reaches domain controllers or management systems it should not.
- Revocation behavior: how quickly a disabled account loses active sessions and whether cached credentials remain usable.
Confirm with the client which gateway version and licensing model is deployed, which AD groups grant access, and whether session recording and MFA are enforced for all users or only for some.
Zero trust access tools broker access to individual applications instead of opening a network tunnel, and they typically depend on an external identity provider for sign-in, device posture and policy. Testing these platforms centers on the broker, the policy engine, the connector that reaches internal applications, and the identity provider configuration that decides who gets in. Weakness areas include policies that are broader than the application list suggests, device posture checks that can be satisfied by an unmanaged device, connectors with more network reach than the application needs, and application consent or token settings that extend access beyond intent. The test must confirm which parts are managed by the vendor and which the client controls.
- Policy scope: whether each application policy matches only the intended users, groups and device conditions.
- Identity provider dependency: how sign-in, MFA and conditional access rules are defined in the external provider and whether the broker trusts them without extra checks.
- Connector reach: the network segments each connector can open, compared with the applications it publishes.
- Device posture: which signals are checked, how often, and whether they can be spoofed or skipped.
- Token and session lifetime: how long access tokens and sessions remain valid after a policy change or account disablement.
Confirm with the vendor how posture and token features behave in the deployed edition, and confirm with the client which identity provider tenant, policy owner and connector hosts are in scope.
What you prepare before a remote access test
Before a remote access test starts, the most important decision is who can stop it. Name a technical owner for each VPN concentrator, remote desktop gateway and zero trust access broker in scope, plus a change authority who can approve or pause testing on the day. Those contacts should be reachable outside business hours, because gateway problems rarely wait for working hours. Also agree the test accounts in advance: a small set of standard user accounts, one account per authentication method being tested (password plus MFA, certificate, SSO), and any privileged or helpdesk accounts that the scope explicitly includes. Record which role each account holds in the directory, which group memberships it inherits, and which MFA factors are enrolled, so that the findings can be traced back to a known identity.
Next, build a written inventory of gateway addresses and platforms. List every public address, hostname and portal URL, the product and firmware or client version where known, the authentication back end (for example, the directory or identity provider it relies on), and whether the device is a physical appliance, a virtual machine or a managed service. Ask the vendor or your asset team to confirm the exact product versions, because the patch level assessment depends on them. Then set change freeze windows that cover the test period and the days either side of it, and agree who may place an exception. Appliance firmware upgrades scheduled during testing will invalidate results and can hide or create the very weaknesses being measured.
Finally, agree how the security operations team will be told, and how credentials and appliances will be protected. Decide whether the SOC will know about the test (an overt test) or only a small group will know (a covert test), and document the notification plan, including the alert channel, the escalation path if a monitoring rule blocks a test source, and the criteria for stopping. Name a backup and rollback contact for each appliance, with a tested procedure for restoring configuration and removing any test accounts or sessions. Last, write down how credentials are handled: where captured or created secrets are stored, who can read them, how long they are kept, and how and when they are destroyed, with written confirmation from the tester. Ask the provider to show how this is recorded in the rules of engagement, which *NIST SP 800-115* describes as a planning deliverable.
What to check before choosing a remote access testing provider
Remote access systems sit on the boundary between the internet and your internal network, so a provider needs both gateway-specific skill and clear written terms. The checks below cover who tests, how the work is bounded, what you receive and how you retest. Ask for the scope, method and deliverables in writing before you sign.
Experience with your gateway and identity platforms
Ask which VPN concentrators, remote desktop gateways and zero trust access products the provider has tested, and how many of those tests were on the same versions you run. Testers who know how a given platform handles authentication, session establishment, split tunneling and administrative interfaces will find weaknesses that a generic web or network checklist misses. Ask how the team confirms current hardening guidance from each vendor and how it handles MFA integration with your identity provider. Request a description of the test environment, not a list of logos.
Written rules of engagement
NIST SP 800-115 treats planning as the phase where rules are identified and management approval is documented, and its Appendix B provides a rules of engagement template you can use as a reference. Confirm the permitted source addresses, timing windows, accounts that may be used, any denial-of-service restrictions and the escalation contact for a finding that affects production. A provider that will not put these rules on paper before work begins is a warning sign.
Independence from the team that runs your systems
Your testers should not be the people who configured, operate or approved changes to the gateways they assess. PCI DSS requirement 11.4.3 expects external testing by a qualified party with organizational independence, and the same logic applies to any assessment you rely on for an auditor or customer. Ask who at the provider signs the report, whether any staff have worked on your deployment, and how conflicts are declared.
Sample report structure
Ask for a redacted sample report before you choose a provider. A useful report separates the exposure of each service from the authentication and MFA results, lists patch level against the vendor advisories the provider checked, and records what a connected device could reach once inside. Each finding should carry evidence, affected assets, a risk rating with its rationale and a specific remediation step. If the sample reads as a generic scanner export, expect the same in your engagement.
Retest terms
Find out whether retesting is included, how many rounds it covers and how long the provider keeps the test environment and evidence available for it. Retest scope should be agreed in the original statement of work, since a finding closed on paper but not verified in production is still open for an auditor. Ask whether retesting after a gateway upgrade or a change in MFA policy is a fixed-scope addition or a separate quote.
Secure handling of client data and credentials
A remote access test often produces test accounts, session tokens, configuration exports and captured authentication data. Ask where that material is stored, who can access it, how long it is kept and how it is destroyed at the end of the engagement. Confirm that test credentials are unique to the engagement, rotated or disabled afterward and never reused. Get these handling rules in the statement of work so you can hold the provider to them.
Remote access and VPN testing questions buyers ask
How much does a remote access and VPN test cost?
The price follows from the written scope, and DeployOpen does not publish a price list. The main cost drivers are the number of remote access platforms in scope (VPN concentrators, remote desktop gateways, zero trust access brokers), how many authentication paths and user roles must be tested, whether the test includes post-access reach into internal segments, and how many retest rounds are planned. Ask any provider for a quote that lists each platform, each authentication method (passwords, MFA, certificates, single sign-on), the environments covered (production, staging or both), and whether reporting and a retest round are included. A one-time assessment and a recurring retainer for continuous testing are priced differently, so ask which one is being quoted.
How long does a remote access test take?
Duration is set by the number of platforms, the depth of authentication testing and how much time the client needs to approve access, schedule windows and review findings. The planning phase is where rules of engagement and management approval are documented, following the four-phase structure in NIST SP 800-115. Testing the post-login reach of a connected device usually takes longer than testing the login page alone, because each reachable segment must be validated. Ask for a timeline in the written scope that separates planning, testing, reporting and the retest window, and confirm which dates depend on your change board or vendor support contracts.
What does the client need to provide for a VPN test?
Most of the work depends on access and information the client controls. Expect to provide a named technical contact, a list of in-scope gateways and their management interfaces, test user accounts for each role and MFA method, the configuration baseline for VPN, gateway and identity provider settings, and a rules of engagement document signed by someone with authority over the systems. Where testing reaches production, the client should confirm change windows, monitoring thresholds and who can stop the test. For testing reached from inside the network, the client also needs to provide a managed starting point, such as a device on a specified network segment, so that results are reproducible.
Can our own team run a remote access penetration test?
Yes, an internal team can test its own remote access, and PCI DSS allows internal penetration tests by a qualified internal resource, provided that resource has organizational independence from the systems it tests. In practice, the team should be able to show it follows a documented methodology such as the one described in NIST SP 800-115, keeps records of its rules of engagement, and reports findings to someone outside the team that manages the platform. Many organizations use internal staff for routine checks and an external party for an independent assessment. Ask an external provider to explain how it will work alongside your team, which parts it will repeat and which it will leave to you.
Does a remote access test satisfy PCI DSS or CIS Controls requirements?
A test can support these requirements, but it does not certify compliance on its own. PCI DSS requirements 11.4.2 and 11.4.3 call for internal and external penetration testing at least every 12 months and after significant changes, and requirement 11.4.1 defines what counts as internal and external testing. CIS Controls v8.1 Safeguards 18.2 and 18.5 ask for annual external and internal penetration tests. Whether your remote access platforms fall inside these requirements depends on your cardholder data environment and the scope your assessor accepts. Confirm the scope and the qualifications needed with your Qualified Security Assessor or auditor before you commission the work, because DeployOpen prepares evidence but does not issue audit reports or attestations.
How does retesting work after we fix the findings?
Retesting checks whether each reported finding is closed, and it should be part of the written scope rather than a free-form request after the report. Typically the client applies fixes, records what changed, and asks for a targeted retest of the affected controls, such as MFA enforcement, gateway patch level, session timeouts or access policy. The report should list each finding with its status before and after retesting, and any accepted residual risk should be documented with an owner. Ask whether the retest round is included in the quote, how many rounds are covered and what evidence the provider will supply for your auditor.
Can a remote access test run against production with a live user session?
It can, but only when the rules of engagement cover it explicitly and the client accepts the operational risk. Testing against production is common for remote access, because gateways and identity configuration are often only fully representative there. The rules should name the test accounts, the time windows, the monitoring team that will be informed, the actions that are excluded, and how a session will be stopped if it affects real users. Avoid using a real employee's session for testing. Dedicated test accounts with the same policies as production give a representative result without exposing staff credentials or disrupting their work.
What should a remote access test report include?
A useful report explains the scope tested, the method, the rules of engagement followed, and each finding with its evidence, affected platform, severity rationale and recommended fix. For remote access, findings typically fall into categories such as exposed management interfaces, weak or bypassable MFA, outdated gateway software, overly broad access policies and paths from a connected device into internal systems. Ask for an executive summary for leadership, a technical section for administrators, and a clear list of what was out of scope. Confirm with your auditor whether they need a particular format before the test starts.
How DeployOpen scopes, tests, reports and retests remote access
DeployOpen treats remote access as a set of entry points with their own authentication and reachability risks, so each engagement starts with a written scope covering the gateways, identity sources and internal networks a connected device can reach. Testing, reporting and retesting follow the same agreed boundaries, and the client decides in advance what evidence is needed for an auditor or customer.
How we scope
- Engagements are fixed-scope, with the VPN concentrators, gateways and access tools listed by name and address range in writing.
- The written scope states which user accounts, MFA methods and device profiles are in bounds for authentication testing.
- Scope records whether testing covers reachability from a connected device into internal or cardholder networks, and which systems are off limits.
How we build
- Testing approach is agreed in advance, including whether the test is overt or covert and which staff know it is happening.
- Test accounts, source addresses and rules of engagement are documented before work starts, in line with the NIST SP 800-115 planning phase.
- Checks cover exposure, authentication and MFA behavior, patch level and what an authenticated remote session can reach once connected.
How we hand over
- The report maps each finding to the affected gateway, the authentication weakness and the internal paths validated during testing.
- Each finding includes a remediation step the client's platform or network team can apply and verify without guessing.
- Evidence is organized so a client can show an assessor or customer which controls were tested, when and against which scope.
How we support
- Retesting checks each closed finding against the same gateway and account conditions used in the original test.
- Ongoing support and continuous testing are available as a retainer for teams that change remote access tooling often.
- Retests after a significant change to remote access infrastructure should be confirmed in the written scope at the start of the engagement.
