Is MFA enforced on all remote access (VPN, RDP, remote network admin)?
Ransomware carriers ask this question because exposed remote access is how a large share of the claims they pay actually began.
What the carrier is actually asking
The carrier is asking about every route into the network that does not start inside it: the corporate VPN, any remote desktop path, jump hosts, remote network administration, and the management interfaces of your own infrastructure. Some forms add remote monitoring and management tooling, which matters greatly if you are a service provider.
The question is about the network perimeter, so a Microsoft 365 tenant can only answer part of it. How much depends on whether your remote access is federated to Entra ID.
Why it is underwritten
Exposed or single-factor remote access is one of the two initial access vectors that dominate ransomware claims, alongside phishing. It is also the vector a carrier can scan for from the outside, which means the answer you give may be compared against an external scan of your address space before a quote is issued. Answering yes while an RDP port responds on a public address is a poor position to be in.
Where the answer lives in Microsoft 365, Entra ID, and Azure
Where remote access authenticates against Entra ID, the answer is measurable in the same way as any other application. Where it authenticates against a local appliance, a RADIUS server, or a standalone firewall account database, it is not, and the evidence has to come from that system.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Entra ID | Conditional Access policies scoped to the VPN or network access application, where the VPN federates to Entra | The VPN application is a named cloud app in an enforced policy requiring multi-factor |
| Entra ID | Sign-in logs filtered to the VPN or gateway application | Successful sign-ins show a multi-factor claim, which is the difference between a policy existing and a policy applying |
| Entra ID | Named locations and trusted IP configuration | Trusted-location exclusions do not silently disable the requirement for the office ranges that a VPN terminates into |
| Azure | Azure Bastion, just-in-time VM access, and network security group rules for ports 3389 and 22 | No management port is open to the internet from an Azure network security group, and administrative access to virtual machines is brokered rather than direct |
| Outside the tenant | VPN concentrator, firewall, RADIUS, or RMM console | Configuration evidence from that system. Insurance Posture cannot read it, so this portion of the answer is attested |
A defensible position is often "yes for cloud-federated access, verified; yes for the VPN appliance, attested with a configuration export dated this month". Carriers do not penalise precision on the application. They penalise a yes that turns out to have covered only part of the estate.
What a defensible yes requires
- Every remote access path is enumerated first, including the ones maintained by a third party or left over from a previous network.
- No management port is reachable from the public internet, since a second factor on a service that should not be exposed at all is the wrong answer to the wrong question.
- Where access is federated to Entra ID, the requirement is proved from sign-in logs rather than from the policy list.
- Where access is not federated, you hold dated configuration evidence from the appliance itself.
- Third-party and vendor remote access is covered by the same requirement, not exempted by convenience.
How this answer goes wrong
The most damaging error is answering for the VPN and forgetting what else is exposed. Ransomware intrusions repeatedly begin at a remote desktop gateway that predates the current VPN, a firewall management interface listening on the public side, or a vendor support tunnel nobody owns. None of those are the VPN, and all of them are remote access.
The subtler error is a trusted-location exclusion. Excluding the office IP ranges from the multi-factor requirement is reasonable for an office network, and unreasonable when the VPN terminates into those same ranges, because every remote session then arrives already exempt.
Frequently asked
Our VPN uses certificates rather than MFA. Is that a yes?
Often yes, and worth explaining in the notes. A device certificate plus user credentials is two factors in substance. Carriers accept it more readily when you describe it than when you leave them to assume a password-only VPN.
We have no VPN, everything is SaaS. How do we answer?
Answer not applicable and say why, then make sure the cloud access question carries the weight. A modern estate with no inbound network path is a strong position, but only if the application shows the underwriter that this is deliberate rather than an omission.
Does RDP inside the network count?
The question is about remote access, so internal workstation-to-workstation RDP is usually treated under network segmentation instead. It still matters to the underwriter, because lateral movement over RDP is what turns one compromised laptop into a domain-wide event.
What about remote monitoring and management tools?
If you are a service provider, treat this as a separate and more serious question. RMM access to client environments is the highest-consequence remote access you hold, and several carriers now ask about it by name.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture