Answering the Cyber Insurance RDP and Remote Access Question

To answer the cyber insurance RDP and remote access question, copy the exact application question, inventory every remote access path, and verify exposure, authentication, MFA, destination and provider access from current configuration. RDP use, direct internet exposure, placement behind a VPN or gateway, and MFA enforcement are separate facts, so record each one. Forms vary, and no configuration or answer guarantees eligibility, pricing, coverage, renewal, limits or claim payment.

This guide establishes how remote connections reach company systems. The companion guide to the admin accounts question establishes who holds administrative power. RDP is only one possible remote access method, so "we do not use Remote Desktop" is not a complete access inventory. This is not legal advice. If wording or scope is ambiguous, ask your broker or carrier in writing before signing.

What is the application actually asking?

It is asking what your exact form says, including its definitions and application period. Split the wording into separate facts so that one yes or no does not cover things nobody checked.

1. Is RDP used anywhere?
2. Is an RDP service directly internet-accessible?
3. Is RDP reachable only after a VPN, Remote Desktop Gateway, bastion or another controlled gateway?
4. Does the actual remote access path enforce MFA for every in-scope user?
5. Are there other remote access methods, even if RDP is absent?

A company can use RDP without exposing it directly, or have no RDP and several unreviewed remote access tools. The copy of At-Bay's Cyber Ransomware Supplemental Application checked for this guide is marked AB-CYB-RWS 09/2025 and Cyber Renewal Insurance Application. Question 10 asks where MFA is deployed and includes "Remote Access (including VPNs)". Question 17 asks which solutions the applicant uses "to enable remote access to its network" and separately lists RDP, VPN solutions, RMM software, SASE or Zero Trust Network Access, and other tools such as TeamViewer, Splashtop and VNC.

That is one carrier's form, not a universal taxonomy, and your carrier may ask something different. Treat it as a reason to inventory the methods separately, then answer your own form.

Which remote access paths belong in the inventory?

On the first pass, list every way a person or provider can connect to company systems from outside the network. Narrow the list only where your form's wording clearly excludes an item, and keep a note of what you excluded and why.

• VPNs, including VPN features on firewall appliances and cloud-hosted VPNs
• Microsoft Remote Desktop Protocol and Remote Desktop Gateway
• Virtual desktop, bastion, zero-trust network access or SASE paths, where actually used
• Vendor support products such as TeamViewer, Splashtop, AnyDesk, VNC or similar tools (named as examples, not recommendations)
• Your IT provider's remote monitoring and management (RMM) platform
• Remote access to servers, workstations, firewalls, hypervisors, backup consoles and other infrastructure
• Cloud administration portals and remote support paths, when the application wording includes them
• Dormant, emergency, temporary, legacy and vendor-installed paths

For each path, capture the owner, users, source, destination, exposure, authentication, MFA enforcement, privilege, logging, standing versus time-limited access, and last verification date.

NIST SP 800-46 Revision 2 offers useful vocabulary. It sorts enterprise remote access into tunneling, application portals, remote desktop access and direct application access, and it says a remote desktop solution "gives a teleworker the ability to remotely control a particular PC at the organization". It also separates direct remote desktop access from indirect access through an intermediate server. That is enterprise security guidance, not a small-business insurance requirement.

What does a VPN establish, and what does it not establish?

A VPN can put an access-control boundary in front of internal services. It says nothing by itself about other paths or about how the VPN is configured, so owning one answers only part of the question.

Having a VPN does not prove that:

• RDP is not also exposed by another forwarding rule or public cloud rule
• MFA is enforced on the VPN for every relevant account
• The VPN is patched or correctly configured
• RDP authentication itself uses MFA
• Vendor RMM or support tools follow the VPN path
• The configuration satisfies every carrier's wording

The CISA StopRansomware Guide treats these as separate jobs. It advises limiting RDP and other remote desktop services, auditing the network for systems using RDP, closing unused RDP ports, applying MFA and logging RDP login attempts. It separately advises updating VPNs and implementing MFA on all VPN connections, and requiring that authorized RMM solutions be used only over approved remote access solutions. That is government security guidance, not insurance wording.

Not every company must deploy a VPN, and neither a VPN nor a gateway automatically makes RDP safe or compliant with an insurance form. Gateways show the same limit. Microsoft's documented integration of Remote Desktop Gateway with Microsoft Entra multifactor authentication describes an authentication flow in which policy conditions, the user's primary credentials, and a successful secondary challenge all have to be satisfied before access is granted. So "we have a gateway" is not the evidence. The configured policy and the user's MFA status are. This is one bounded example, not a product recommendation.

MFA scope and exclusions need their own evidence, which the guide to answering the MFA section of an application covers.

How can the company verify its answer safely?

Review the configuration of systems you own or are explicitly authorized to assess, then reconcile what you find against your inventory. Keep every check defensive: this work does not call for testing credentials, probing other parties' systems or attempting exploitation.

• Review current firewall NAT and port-forwarding rules, cloud security groups and gateway publishing rules.
• Reconcile those rules with current asset and remote access inventories, and investigate rules that point to systems nobody can explain.
• Review VPN, RD Gateway, RMM, support-tool, identity-provider and MFA policy settings.
• Ask your IT provider for product-specific documentation and current tenant or configuration evidence. "We handle it" is not proof.
• Check user and vendor assignments, exclusions, disabled accounts and emergency access.
• Use authorized external exposure findings from your own approved scanner, a carrier scan, your security provider or another authorized assessment.
• Review authentication and connection logs for the relevant products.

A clean scan of common ports is point-in-time evidence only. It can miss paths that use different ports, cloud relays, outbound agents, dormant rules, temporary exposure, alternate IP addresses or systems outside the scanned scope. It does not establish that every remote access method is controlled.

A port number alone does not prove which service is behind it either. RDP can listen on a non-default port, and something else can occupy a familiar one. Confirm the service from the destination system's configuration before recording it.

How should vendor and IT-provider access be documented?

Document each provider's access as its own entry, with the same detail you would require for an employee path. A provider's assurance that access is managed does not tell you which path it uses or what it reaches.

• Provider organization and named or attributable account owners
• Access product and connection path
• Systems and privilege reachable
• Standing, scheduled, just-in-time or time-limited access
• Authentication and MFA enforcement
• Approval or ticket requirements
• Logging, review and account-removal process
• Shared accounts, former providers and unresolved exceptions

Keep the connection path and the privilege as different facts. A vendor tool can reach one workstation with broad rights, or many systems with narrow ones. The admin accounts guide covers who holds that privilege, while this record covers how the connection arrives.

What belongs in the evidence pack?

Keep a dated set of records that lets a reviewer trace each statement on the application back to verified configuration. Attach it separately rather than overloading a short form field.

• Dated remote access inventory
• Copy or exact transcription of the application question and definitions
• Firewall, cloud rule and gateway review results
• Authorized external exposure findings, with scope and date
• Authentication and MFA configuration evidence
• Provider and vendor access records
• User, group and role assignments, with exclusions
• Relevant connection and authentication logs
• Account or access review date and reviewer
• Unresolved exceptions, compensating controls, owner and target date

Screenshots are supporting artifacts. They do not substitute for reconciling the whole inventory. Anything you cannot yet verify stays listed as unknown or as a documented exception with an owner, rather than being rounded up to a yes.

Fictional 35-person company example

This example is invented. A 35-person company believes it has no RDP exposure. Its review finds an old firewall forwarding rule to an accounting server, and a separate vendor support tool that uses a different remote access path.

Here is what it can honestly report today, keeping each fact apart:

• RDP present or absent: Present. Found on March 12: the accounting server accepts RDP, confirmed from the server's own settings rather than from a port number.
• Direct exposure or protected access: Directly internet-accessible by current configuration. Found on March 12: the forwarding rule reaches that server without a VPN or gateway in front of it. This is a current exception.
• Separate vendor support path: Present. The support tool is installed by the vendor and does not use the firewall rule, so closing the rule would not address it.
• MFA status: Unknown for the vendor tool, because the vendor has not yet supplied configuration evidence. No MFA enforcement has been verified on the RDP path through the old rule. Neither is recorded as enforced.
• Current configuration or planned remediation: The rule and the tool both remain in place on the verification date.

The company should not answer "no" to RDP or direct exposure while the old rule exists. A bounded statement looks like this: "Reviewed on March 12. RDP is in use on one accounting server and is directly internet-accessible through an existing firewall forwarding rule, recorded as a current exception. A separate vendor support tool also provides remote access; MFA status for that tool is unknown. Documentation is held separately."

Planned action, not completed: confirm whether anything depends on the rule, then remove it, and obtain the vendor's access and MFA evidence, each with a named owner and target date. If the form allows no room for this, ask the broker how to record a partial state. If those actions finish before signing, verify the new state and report it with its date. Remediation does not guarantee coverage.

Fill-in response template

Use one entry per access method, and attach evidence separately.

• Exact application question and form or version:
• Verification date and reviewer:
• Access method or product:
• RDP used (yes, no or unknown):
• Directly internet-accessible (yes, no or unknown):
• Gateway, VPN, bastion or other boundary:
• Source and destination scope:
• Users and vendor or provider:
• MFA status and enforcement point:
• Standing or time-limited access:
• Logging evidence and evidence location:
• Exceptions and unknowns:
• Current truthful response:
• Planned improvement, owner and target date (future work, not current state):
• Broker or carrier clarification requested:

After inventorying each remote-access path, use the SIEM and logging application guide to verify whether VPN, gateway, identity and vendor-access events reach a central platform and how long they remain available.

Sources

• At-Bay, Cyber Ransomware Supplemental Application, AB-CYB-RWS 09/2025
• CISA, #StopRansomware Guide
• NIST SP 800-46 Revision 2, Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security
• Microsoft, Integrate RDG with Microsoft Entra multifactor authentication NPS extension