Mullvad is a single VPN service.
There is no free tier that unlocks into a paid one, no ladder of plans that gate advanced tools behind a higher price, and no bundled suite of adjacent products competing for the same subscription. One payment buys one product: a WireGuard virtual private network, built as native apps for Windows, macOS, Linux, Android and iOS/iPadOS, plus manual configuration support for third-party clients and routers.
Inside that narrow scope, the feature architecture is substantial. Mullvad has built a genuinely deep advanced-protection layer: DAITA, multihop routing, post-quantum key establishment and several methods of disguising VPN traffic so it is harder to identify. DAITA stands for Defense Against AI-guided Traffic Analysis. It is Mullvad’s traffic-shaping feature, designed to alter observable patterns such as packet size, timing and traffic shape. Mullvad’s own platform documentation lists all four of these advanced protections as current across every native app.
That platform table is the right place to start, and also the place to read carefully. A feature appearing on every platform’s list is evidence that it exists there. It is not, by itself, evidence that it behaves the same way everywhere, that it has been implemented with the same engine underneath, or that it works correctly alongside the other advanced features next to it on the same list.
This piece works through what Mullvad’s feature set actually includes, platform by platform, and where Mullvad’s own public record stops answering the question.
The Feature Verdict, Up Front
What kind of feature set is this? A focused, single-service, WireGuard-only VPN with a technically ambitious advanced-protection layer built on top of a deliberately simple core.
Main strength: Mullvad documents DAITA, multihop, post-quantum key establishment and several obfuscation methods across all five native platforms. Together, these form a substantial advanced-protection layer within Mullvad’s focused VPN architecture.
Main limitation: Being listed everywhere is not the same as being proven to work the same way everywhere. Several combinations of these advanced features remain unresolved, while GotaTun’s deployment outside Android is not established in the current record.
Strongest current record: Android. It is the only platform with a confirmed deployment of Mullvad’s newer tunnel engine and the only platform where Mullvad currently documents reproducible-build support, meaning the build process is designed so the same source code and defined build environment produce an identical binary. Independent reproduction of every distributed artifact or channel is not established.
Where the record thins fastest: iOS, where split tunnelling is not listed as supported and there is no distinct Lockdown mode, and any advanced-feature combination beyond DAITA paired with multihop, where Mullvad’s own compatibility record runs out.
This is a feature-architecture verdict. It says nothing about whether Mullvad is safe, private, or worth its price. Those are different questions, addressed in different investigations.
Table A: Features at a Glance
| Feature | What it does | Native platform availability | Main condition or limit |
|---|---|---|---|
| WireGuard | Sole native VPN protocol | All native platforms | — |
| GotaTun | Tunnel engine running WireGuard | Confirmed on Android | Deployment on other platforms not established |
| DAITA | Alters traffic patterns to resist traffic analysis | All native platforms (iOS from app version 2024.7) | Optional; requires a DAITA-capable entry server; real-world efficacy unverified |
| Multihop | Routes through separate entry and exit relays | All native platforms (Android from version 2025.1) | Optional; resistance to coordinated observation unverified |
| Post-quantum key establishment | Adds post-quantum protection to the WireGuard handshake | All native platforms | Covers key establishment only, not the ongoing data channel |
| Shadowsocks | WireGuard obfuscation transport | All native platforms | Server-dependent; efficacy unverified |
| QUIC | WireGuard obfuscation transport | All native platforms | Server-dependent |
| Lightweight WireGuard Obfuscation (LWO) | WireGuard obfuscation transport | All native platforms | First-version rollout dates vary |
| WireGuard-over-TCP / UDP-over-TCP | Fallback transport where UDP is blocked | All native platforms | Performance and efficacy not established |
| Kill switch | Blocks non-tunnel traffic during connection failure | Native on desktop; app-level on Android; via Apple’s framework on iOS | No ordinary disable option on desktop |
| Lockdown / Always require VPN | Blocks traffic even after a deliberate disconnect | Optional on desktop | No distinct mode established on Android or iOS |
| Split tunnelling | Lets selected apps or traffic bypass the tunnel | Native on Windows, macOS and Linux; app-exclusion model on Android | Not listed as supported on iOS |
| Custom DNS | User-specified resolver replacing Mullvad’s default | All native platforms | May replace or override Mullvad’s own content filtering depending on configuration |
| DNS content blocking | Blocks ads, trackers, malware and other categories at the DNS level | All native platforms | DNS-based, not antivirus |
| Server filtering | Country, city, server, provider, ownership and DAITA filters | All native platforms | Ownership labels are company-published metadata |
| Manual WireGuard | Configuration for third-party clients and routers | Current | Does not inherit native app controls |
| SOCKS5 | Application-level proxy | Current | Not a device-wide VPN |
| Device limit | Devices associated with one account | Up to five | Manual and router device-slot treatment against this limit is unresolved |
Table B: Platform Comparison
| Feature | Windows | macOS | Linux | Android | iOS/iPadOS |
|---|---|---|---|---|---|
| WireGuard | Native | Native | Native | Native | Native |
| GotaTun | Deployment not established | Deployment not established | Deployment not established | Confirmed | Deployment not established |
| DAITA | Current, optional | Current, optional | Current, optional | Current, optional | Current from version 2024.7 |
| Multihop | Current, optional | Current, optional | Current, optional | Current from version 2025.1 | Current listing |
| Post-quantum key establishment | Automatic by default | Automatic by default | Automatic by default | Available with documented controls | Current from August 2024 |
| Obfuscation suite (Shadowsocks, QUIC, LWO, TCP fallback) | Current | Current | Current | Current | Current; LWO’s first version date unresolved |
| Split tunnelling | Native | Native, implementation differs | Native | App-exclusion model | Not listed as supported |
| Kill switch | Native connection-state logic | Native | Native | App-level control | Handled through Apple’s framework |
| Lockdown | Native, optional | Native, optional; early-boot caveat | Native, optional | No distinct mode established | No distinct mode established |
| Custom DNS | Native | Native | Native | Native; interacts with Android’s own Private DNS setting | Native |
| Content blocking | Native | Native | Native | Native | Native |
| Reproducible-build status | Not established | Not established | Not established | Confirmed from version 2025.2 | Not established |
A cell that reads “not established” is different from one that reads “not listed as supported,” and both are different from “no distinct mode established.” None of the three means the feature is impossible on that platform. Each means Mullvad’s current public record stops at a different point, and the distinctions matter for anyone deciding whether a feature will actually be there when they need it.
The Architecture Underneath: WireGuard and GotaTun
WireGuard is the only VPN protocol Mullvad runs natively today. A protocol is the rulebook: the agreed set of rules that determine how a device and a server establish an encrypted tunnel and exchange traffic through it. Mullvad ran OpenVPN as a second protocol for years, but removed it from the desktop app and shut down server-side OpenVPN support on 15 January 2026, closing that path entirely rather than leaving it as a fallback. That single decision is what makes Mullvad’s current architecture genuinely simple: one protocol, one set of rules, no secondary system to secure or document in parallel.
A protocol is not the same thing as the software that carries it out. That software is the tunnel engine. Mullvad’s newer WireGuard implementation is called GotaTun, but its current deployment is confirmed only on Android. The distinction is worth holding onto because it recurs through several features below: WireGuard is the rulebook, GotaTun is the engine that actually runs it inside the app.
Mullvad announced GotaTun, a Rust-based WireGuard implementation, in December 2025. Its deployment is confirmed on Android. Mullvad’s own announcement described desktop and iOS replacement work as following during 2026, but a roadmap statement is not proof that the migration has happened. Current deployment on Windows, macOS, Linux and iOS was not established at the research cut-off.
Android is also the only platform where Mullvad currently documents reproducible-build support. This means the build process is designed so the same source code and defined build environment produce an identical binary. Independent reproduction of every distributed artifact or channel, Google Play, F-Droid and the direct APK included, is not established. That support, confirmed from app version 2025.2, has not been extended to any other platform.
GotaTun explains one part of Mullvad’s underlying implementation, confirmed on Android and not established on the other native platforms at the research cut-off. The next layer is user-facing protection, beginning with DAITA’s attempt to alter recognizable traffic patterns.
Advanced Protections
DAITA
DAITA stands for Defense Against AI-guided Traffic Analysis. It is Mullvad’s name for a set of measures that alter the pattern of a user’s traffic, adjusting the size and timing of data packets, so that an outside observer watching the encrypted connection has a harder time inferring what the user is doing from patterns alone.
DAITA is listed as current on all five native platforms, reaching iOS from app version 2024.7. It is optional, not switched on by default, and it depends on connecting through a DAITA-capable entry server, so its protection is not automatic simply because the feature exists in the app. Mullvad documents a specific combined workflow: DAITA paired with multihop, using a DAITA-capable relay as the entry point and a separately selected relay as the exit.
What Mullvad’s public record does not establish is how effective DAITA actually is. Availability is well documented. Real-world protection against advanced traffic-fingerprinting techniques, coordinated observation, or large-scale correlation across many points on a network is not independently verified in the material Mullvad has published. That gap between “available” and “proven effective” is the same gap that runs through the rest of this section.
Multihop
Multihop routes a user’s traffic through two relays instead of one: it enters through a selected entry relay and exits through a separately selected exit relay. Multihop separates the information available at the entry and exit hops. This does not establish protection against coordinated observers or global traffic correlation.
Multihop is current on all five native platforms, with Android support dating from app version 2025.1. As noted above, Mullvad documents multihop working alongside DAITA through a specific entry-relay configuration. Beyond that pairing, the record thins: multihop’s compatibility with the obfuscation suite or with post-quantum key establishment is, like DAITA’s, not resolved in the current record.
Post-Quantum Key Establishment
Before using the term “post-quantum” any further, it is worth being precise about what it covers. Every VPN connection begins with a handshake: a brief exchange in which the two sides agree on the secret keys that will protect the tunnel. Post-quantum key establishment means Mullvad has added cryptographic material to that handshake that is designed to resist attacks from future quantum computers. Mullvad’s post-quantum enhancement applies to key establishment. The ongoing data channel continues to use conventional symmetric encryption.
Post-quantum key establishment is current on all five native platforms. On desktop it runs automatically by default. On mobile, Mullvad documents user-facing controls rather than a fixed always-on default. Official iOS support launched on 30 August 2024. One boundary carries through every platform: manual WireGuard configurations, run through third-party clients or routers rather than Mullvad’s own apps, do not automatically inherit this workflow. A router running Mullvad’s WireGuard keys is not, by default, doing post-quantum key establishment.
Obfuscation Methods
Obfuscation, in this context, does not mean a second VPN protocol. It means changing how an already-established WireGuard connection appears or travels across the network, so that it is harder for a network operator to identify the traffic as VPN traffic in the first place.
Mullvad currently documents several obfuscation methods, and each carries a slightly different profile.
Shadowsocks disguises WireGuard traffic using a transport originally built for censorship circumvention. It is listed as current on all five native platforms and depends on server-side support.
QUIC carries the obfuscated WireGuard connection over a QUIC-based path, a transport also widely used by ordinary internet services. Its availability is established; its effectiveness at avoiding detection is not. It is current across all five platforms.
Lightweight WireGuard Obfuscation (LWO) is Mullvad’s own obfuscation transport. It is listed as current everywhere, though the exact date it first became available on iOS is not established in Mullvad’s public record.
WireGuard-over-TCP and UDP-over-TCP act as fallback transports for networks that block the UDP traffic WireGuard normally relies on. Both are current across all five platforms.
What none of these methods carries with it is a verified efficacy claim. Mullvad’s documentation confirms that each method is available and that automatic method selection exists on supported platforms. It does not establish the order in which the app falls back between methods, how effective each method is at avoiding detection in specific countries, or how the methods hold up against active probing. Availability, again, is not the same claim as proven performance, and that same open question follows directly into the compatibility table further down this article.
Kill Switch and Lockdown
These two controls are often talked about as one thing. They are not, and Mullvad’s documentation treats them separately.
A kill switch blocks ordinary internet traffic during a defined connection failure, such as the moment the VPN tunnel drops unexpectedly. Lockdown, which Mullvad also calls Always require VPN, goes further: it blocks traffic even after a user deliberately disconnects the VPN or closes the app entirely. The kill switch covers defined connection-failure states. Lockdown extends that blocking policy to deliberate disconnection and app exit.
Four separate qualifications apply here, and they should not be collapsed into one sentence.
On desktop, Mullvad documents connection-state firewall logic functioning as a kill switch with no ordinary user option to disable it, and Lockdown is available as a separate, optional setting.
On macOS specifically, Lockdown carries an early-boot caveat not recorded for Windows or Linux: protection during the earliest moments of system startup is a documented limitation rather than a guarantee.
On Android, kill-switch behavior runs as an app-level control, separate from Android’s own operating-system features, Always-on VPN and Block connections without VPN, which operate independently of Mullvad’s app and can be configured (or misconfigured) on their own.
On iOS, kill-switch behavior runs through Apple’s own VPN framework rather than a Mullvad-built equivalent, and there is no distinct Lockdown mode established on iOS at all.
Across all platforms, Mullvad’s documentation does not fully cover every adverse scenario, an app crash, a sleep and wake cycle, or a network transition between networks, so a claim that the kill switch always fails closed in every circumstance goes beyond what the current record supports.
Split Tunnelling by Platform
Split tunnelling lets a user choose specific apps or traffic to bypass the VPN tunnel entirely, useful for reaching a local printer or a work resource that expects a local network connection while everything else stays protected.
On Windows, macOS and Linux, split tunnelling is native, though the macOS implementation differs from the other two in its specifics. On Android, it works through an app-exclusion model rather than a full routing-table split. On iOS, Mullvad’s current platform table does not list native split tunnelling as supported. That is a statement about what Mullvad currently documents, not a claim about what Apple’s operating system technically permits.
DNS, Filtering and Server Controls
Mullvad provides in-tunnel DNS by default, meaning DNS lookups are resolved through Mullvad’s own infrastructure inside the encrypted tunnel rather than leaking to a local network’s resolver.
Custom DNS lets a user replace that default with a resolver of their own choosing. It is available on every native platform. A custom DNS resolver may replace or override Mullvad’s filtering path depending on configuration, so a user who sets a custom resolver should not assume ad and tracker blocking will necessarily keep working alongside it.
Mullvad also offers DNS-based content filtering, covering categories including ads, trackers, malware, gambling, adult content and social media domains. This operates at the DNS level, checking which domains a device is trying to reach. It is not antivirus software, does not scan file contents, and does not inspect traffic the way endpoint security tools do.
Server selection is detailed: country, city, individual server, hosting provider, an Owned-versus-Rented filter, a DAITA-capability filter and custom saved lists are all current. One caveat applies specifically to the ownership metadata: labels like Owned and Rented are company-published information about Mullvad’s infrastructure. They are useful context, but they are not independently verified proof of legal title, physical custody, or which party actually controls a given server at any given moment.
Account and Device Features
Mullvad’s account model uses a 16-digit account number and a shared-secret login credential rather than an email address and password. This is a deliberate design choice that avoids collecting a conventional identifier at signup. It is not the same claim as calling the account anonymous, since payment methods and recovery processes can introduce other identifying information depending on how a user pays.
Up to five devices can be associated with one account at a time. Adding a sixth requires removing an existing device first. This is a limit on associated devices, not a guarantee of five simultaneous active connections, and it is not the same thing as five separate app installations.
Beyond that core model, several operational details remain unresolved in Mullvad’s published documentation: multi-factor authentication, whether and how account numbers can be rotated, how session inventories and expirations work, login throttling behavior, and exactly how quickly a removed device’s access is revoked. The accurate description for each of these is “not established,” not “does not exist.”
Manual WireGuard and Router Support
Running Mullvad through a third-party WireGuard client or a compatible router is a different product mode from the native apps, not a lesser version of them. Mullvad supplies the configuration files needed to set this up, but does not offer a native, Mullvad-built router application or a branded router product.
What manual and router configurations do not automatically inherit from the native apps:
- Lockdown
- The native kill switch
- DAITA
- The native post-quantum key-establishment workflow
- Automatic obfuscation
- Split tunnelling
- Native app update handling
- Native DNS firewall controls
A router running Mullvad’s WireGuard keys is providing WireGuard encryption and Mullvad’s server network. It is not, on its own, providing any of the items above unless a user has separately configured equivalent protection at the router or firewall level.
Browser, Proxy and Adjacent Tools
Mullvad Browser is a separate product from the VPN, built for privacy-hardened browsing. Its fingerprinting-resistance features do not transfer to, or change, the VPN feature verdict in this article; it is a distinct product with its own separate evaluation.
Mullvad also documents browser-extension functionality, though the exact boundary of that product, whether it constitutes a standalone, clearly bounded extension separate from the browser and the VPN app, is not clearly established in current official material.
SOCKS5 is an application-level proxy Mullvad offers as a separate tool. It routes traffic for individual applications rather than the whole device, and its behavior depends on the underlying tunnel and DNS configuration a user has set up. It is not a substitute for the device-wide VPN.
Diagnostic tools currently offered include a connection check, a DNS leak test, WebRTC guidance for browsers, a desktop command-line interface, and API connectivity tools. These are point-in-time checks. They confirm a connection’s state at the moment they are run, not continuous, ongoing assurance.
Removed Features
The following table separates features Mullvad has actively discontinued from features that were never offered. Removed features have a clear chronology; a removal is not automatically a defect, since some reflect deliberate simplification following the move to a WireGuard-only architecture, while others represent lost functionality with no current replacement.
Table D: Removed Features
| Feature | Removed | Detail |
|---|---|---|
| Port forwarding | New ports stopped May 2023; existing ports removed July 2023 | No replacement currently offered |
| OpenVPN (desktop) | Server-side support ended 15 January 2026 | Superseded by the WireGuard-only architecture |
| Manual OpenVPN | Non-functional after the server shutdown | No replacement; manual WireGuard remains available |
| OpenVPN bridge (obfuscation mode) | Non-functional | Superseded by current WireGuard obfuscation methods |
| Leta search proxy | Shut down 27 November 2025 | No replacement currently offered |
| 2022 experimental post-quantum tunnel | Superseded | Replaced by the stabilized post-quantum key-establishment feature |
Port forwarding and Leta represent capability that existed and is now gone with nothing to replace it. OpenVPN’s removal simplified Mullvad’s native protocol architecture, although users who depended on OpenVPN-specific compatibility or configurations lost that option.
Missing or Unestablished Feature Classes
These are features Mullvad’s current public record does not establish as offered at all. This is a statement about the present record, not a prediction about the future.
| Item | Status |
|---|---|
| Dedicated or static personal IP | No current offering established |
| Smart DNS | No current offering established; distinct from the public encrypted DNS Mullvad does offer |
| Residential IP | No current offering established |
| Dedicated streaming servers | No current offering established |
| A named gaming mode | Not documented as a distinct feature |
| Business or team account administration | No current offering established |
| Family plan | No current offering established; the five-device limit is not a family identity system |
| Native router application | No current offering established; manual third-party firmware configuration only |
| Hardware product | No current offering established |
Table C: Advanced-Feature Compatibility
The individual advanced features described above are, on the evidence, real and current. The remaining question is not whether they exist. It is whether they work together, and whether they work the same way on the platform a given user actually runs.
| Combination | Documented status | Platform or condition | Evidence boundary |
|---|---|---|---|
| DAITA + multihop | Supported through a documented workflow | DAITA-capable entry relay, separately selected exit | Official workflow exists |
| DAITA + obfuscation | Unresolved | Platform and server dependent | No complete compatibility record |
| DAITA + post-quantum | Unresolved | Native apps | Separate availability is not proof of compatibility |
| Multihop + obfuscation | Unresolved | Platform and server dependent | No complete compatibility record |
| Multihop + post-quantum | Unresolved | Native apps | No complete compatibility record |
| Android split tunnelling + Block connections without VPN | Unsupported | Android operating-system control | The OS control blocks excluded apps |
| Android local-network access + Block connections without VPN | Unsupported | Android operating-system control | The OS control blocks local access |
| Custom DNS + content blocking | Configuration-dependent / potentially overriding | Native apps | A custom resolver may replace or override Mullvad’s filtering path depending on configuration |
| Manual WireGuard + multihop | Platform-limited | Third-party client or router | Manual topology, not the native workflow |
| Router + DAITA | Not inherited | Router | Native implementation is absent |
| Router + post-quantum workflow | Not inherited | Router | A separate mechanism would be required |
| Router + native kill switch | Not inherited | Router | Router firewall rules substitute instead |
DAITA plus multihop is the only advanced-feature pairing in the table with a clearly documented native workflow. The remaining rows include unresolved combinations, operating-system conflicts, configuration-dependent behavior and features that manual or router setups do not inherit. Mullvad’s advanced-protection layer should be read as a set of individually available features, not as evidence of one integrated system that has been proven to work as a whole.
Platform-by-Platform Summary
Windows, macOS and Linux share the WireGuard-only protocol, the full advanced-protection layer, native split tunnelling, custom DNS and the connection-state kill switch with optional Lockdown. They are not identical to one another: macOS carries the early-boot Lockdown caveat and its own split-tunnelling implementation, Linux’s behavior depends on each distribution’s own package management and firewall setup, and Windows and macOS share an update path that Linux does not. GotaTun deployment and reproducible-build status remain unresolved on all three.
Android has the strongest current evidence in several specific areas: confirmed GotaTun deployment, reproducible-build support and detailed documentation of Android operating-system controls. It also carries its own complexity: Android’s own Always-on VPN and Block connections without VPN settings operate independently of Mullvad’s app and can conflict with split tunnelling and local-network access, device manufacturers’ battery-management systems can affect app behavior, and Android TV lacks the Block connections without VPN control entirely.
iOS and iPadOS carry the full advanced-protection layer, DAITA from 2024.7, post-quantum key establishment from August 2024, and current multihop and obfuscation listings, but the platform’s current documentation does not list native split tunnelling as supported, there is no distinct Lockdown mode established, GotaTun deployment is unresolved, and reconnect behavior is documented by Mullvad itself with limited independent verification.
Manual and router configurations offer genuine flexibility and third-party control, but do not inherit the native apps’ kill switch, Lockdown, DAITA, post-quantum workflow, automatic obfuscation, split tunnelling, update handling or DNS firewall controls. This mode is best evaluated on its own terms rather than measured against the native apps as though it were a lesser version of them.
Who This Feature Set Fits
Two groupings emerge directly from the evidence above.
Users for whom this architecture may be a stronger fit:
- Readers who want one focused VPN rather than a bundled security suite
- Technically engaged users comfortable reading platform-specific documentation
- Users who value granular server controls: country, city, provider, ownership and DAITA filters
- Primarily desktop or Android users, with Android carrying confirmed GotaTun deployment, reproducible-build support and more detailed documentation of operating-system controls
- Users comfortable with manual WireGuard configuration who accept losing native app controls in exchange for router or third-party client flexibility
Users for whom the current feature record may be less complete:
- iOS users who specifically need split tunnelling, which is not currently listed as supported
- Users who expect every advanced feature to work seamlessly together, since most combinations beyond DAITA-plus-multihop remain unresolved
- Users who relied on port forwarding, which was removed with no replacement
- Users expecting a dedicated IP, Smart DNS, or family or business account administration, none of which are currently offered
Related STACK Investigations
Several questions this article deliberately does not resolve are covered elsewhere. Mullvad’s kill switch, Lockdown behavior and GotaTun’s incomplete rollout raise a natural next question about infrastructure assurance, addressed in Is Mullvad VPN Safe?. The account model and DNS and server metadata discussed above raise questions about data exposure, addressed in Is Mullvad VPN Private?. And the company structure and infrastructure control behind this product architecture are addressed in Who Owns Mullvad VPN?
Conclusion
Mullvad’s feature set is built around one decision: run a single, WireGuard-only VPN service and build a substantial advanced-protection layer within that focused product, rather than expanding into a wider suite of adjacent services. Within that scope, DAITA, multihop, post-quantum key establishment and a multi-method obfuscation suite are current across all five native platforms.
The central tension is between that platform-wide breadth and what sits beneath it. A feature listed as available everywhere is not automatically documented to work identically everywhere, or to work in combination with the other advanced features next to it on the same list. The decisive question for any individual reader is narrower than the tension itself: whether the specific combination of features they need, on the platform they actually use, is documented to work together as intended.
Users who want a focused VPN, who are comfortable reading platform-specific documentation, and who run desktop or Android are working from the strongest part of Mullvad’s current record. Users who need iOS split tunnelling, who expect several advanced features to function together as one system, or who are relying on manual or router configurations to carry native-app protections with them, are working from a thinner part of that same record. Reproducible builds remain confirmed for Android only, and GotaTun’s rollout outside Android remains a roadmap rather than a completed migration.
None of this resolves, one way or the other, whether these gaps matter enough for a given reader. That judgment depends on which platform someone runs and which features they actually need working together, not on how the feature list reads on its own.
The STACK View
Mullvad’s feature architecture is more coherent than a simple feature count suggests. DAITA, multihop, post-quantum key establishment and several obfuscation methods are current parts of the native product record, not merely announced ideas. But the evidence is much stronger for individual availability than for combined operation and cross-platform parity.
That distinction is the load-bearing one. Mullvad documents a broad advanced-protection layer, but only a limited set of feature combinations is clearly mapped. The fairest reading is not that the system is incomplete or that the features fail, but that the public record does not yet establish them as one uniformly documented, integrated layer across every platform.
Frequently Asked Questions
What features does Mullvad VPN have? Mullvad is a focused, WireGuard-only VPN with an advanced-protection layer that includes DAITA, multihop, post-quantum key establishment and multiple obfuscation methods, offered through native apps on five platforms. Listing on a platform does not guarantee identical implementation or defaults across every platform.
What is DAITA? DAITA stands for Defense Against AI-guided Traffic Analysis. It is a traffic-shaping feature that adjusts packet size and timing to make Mullvad traffic harder to analyze from the outside. Its availability is well documented, but its real-world effectiveness against advanced fingerprinting or correlation techniques is not independently established.
Does Mullvad have multihop? Yes, multihop is current on all five native platforms, routing traffic through separately selected entry and exit relays. Its resistance to coordinated or large-scale traffic correlation is not independently verified.
Is Mullvad post-quantum? Mullvad’s post-quantum enhancement applies to key establishment, the handshake that sets up a tunnel’s keys. The ongoing data channel continues to use conventional symmetric encryption, so this should not be read as full-channel post-quantum protection.
What is GotaTun? GotaTun is Mullvad’s own WireGuard tunnel engine, the software that runs the WireGuard protocol inside the app. Its deployment is confirmed on Android only; deployment on Windows, macOS, Linux and iOS remains unresolved in Mullvad’s public documentation.
Does Mullvad have split tunnelling? Yes, on Windows, macOS, Linux and Android, though the implementation differs by platform. Mullvad’s current platform table does not list native iOS split tunnelling as supported.
Does Mullvad have a kill switch? Yes. Desktop platforms use native connection-state firewall logic with no ordinary disable option, while Android and iOS rely on app-level or operating-system-level controls that are not identical to the desktop implementation.
Does Mullvad still support OpenVPN? No. OpenVPN was removed from the desktop app, and server-side OpenVPN support ended on 15 January 2026. WireGuard is now the only native protocol.
Does Mullvad support port forwarding? No. Port forwarding was removed in 2023 and there is currently no replacement.
Does Mullvad offer dedicated IPs? No current offering is established. Individual server selection is available, but that is not the same as a dedicated or static personal IP address.
Does Mullvad work on routers? Yes, through manual WireGuard configuration on compatible router firmware. This mode does not inherit the native apps’ kill switch, Lockdown, DAITA, post-quantum workflow or other built-in controls.
How many devices can use Mullvad? Up to five devices can be associated with one account at a time. This is a limit on associated devices, not a guarantee of five simultaneous active connections.
Does Mullvad block ads and trackers? Yes, through DNS-based content filtering covering categories like ads, trackers and malware domains. This works at the DNS level rather than as antivirus software, and a custom DNS resolver may replace or override it depending on configuration.
Does Mullvad work differently on iPhone? Yes. iOS currently lacks listed split tunnelling support and a distinct Lockdown mode, and GotaTun deployment on iOS remains unresolved, even though DAITA, post-quantum key establishment, multihop and obfuscation are all current on the platform.