2fast keeps your TOTP seeds in one encrypted file you can back up anywhere

The whole state of the app is one file

2fast is described as a free, open source two factor authenticator for Windows and other platforms, and the acronym stands for two factor authenticator supporting TOTP. The homepage is 2fast-app.de and the licence is GPL-3.0.

The central design decision is stated in the About section: 2fast has the ability to store the encrypted data at a place of your choice instead of a third party cloud location.

That choice drives everything else. All data is stored in a single encrypted file, encrypted with AES using a password-based key derived by PBKDF2. Because it is one file, backing up and restoring is a single file operation, and because you choose where it lives, the backup target can be a WebDAV server, a synced folder, or a USB stick.

The feature list makes one more claim that is unusual for an authenticator: the possibility to send the data file to your colleagues and friends to securely share logins. That is only possible because the file is self contained and password protected, and it is also the single most consequential thing the app lets you do, because the file plus the password is the entire credential set.

Everything else works locally. There is no extra account, registration or login needed, and no Internet connection is needed except for WebDAV use. For a second factor, that is the correct default, since the service you are protecting is not the one holding your keys.

TOTP by the book, and the accounts it is meant to work with

The authenticator algorithm is the widely accepted TOTP algorithm, specified in RFC 6238, and the README says it works with accounts from Google, Microsoft, Facebook, PayPal and similar.

Using the standard is the whole reason the app is usable at all. TOTP is time-based one-time passwords, and the point of the standard is that a service and an authenticator agree on the algorithm and the shared secret, so the code your phone shows is the code the service expects. A proprietary variant would be a different product, and one that could not be used with the large services most people need.

The implementation is the Otp.NET library, which is in the repository top level alongside the ZXing.Net.Uno scanning library and a WebDAVClientPortable/ directory. The ZXing dependency is the barcode scanning library, so the camera-based account setup, the familiar square-with-dots setup flow, is a NuGet package rather than something written from scratch. The Otp.NET and ZXing references are not incidental, they are the two halves of the product: one turns a shared secret into a rotating code, the other gets the shared secret into the app.

The WebDAV client is also a separate library in the tree, which matches the feature list entry on synchronisation via a WebDAV server, for example ownCloud or Nextcloud, as a storage location.

Windows 10 and UWP today, everything else on Uno and in progress

The platform situation is where the project is candid, and the README lists it plainly.

Currently released is Windows 10 and later, as a UWP .NET native application. Under development are UWP with .NET 10 AOT, and Android, iOS, Linux and macOS, all built on the Uno platform, with the Android releases linked separately.

So the cross platform ambition is real and built on a specific technology choice rather than being a hope. Uno is what lets one C# and XAML codebase target Android, iOS, Linux and macOS, and the UWP application is the same idea applied to a platform that already had a .NET native path.

The build is on the UNOversalTemplate, which the README names as the template the project is built with, and the repository top level contains a directory of that name.

There is a commercial wrinkle in the licensing terms. The feature list says free for desktop OS and fee required for mobile OS, and the installation section repeats that a mobile application is currently being worked on. So the mobile builds, which are the ones most people would want for an authenticator, are the ones that are both unfinished and paid. The Android builds do exist as releases on the repository releases page, so a sideload install is possible today, but the README is explicit that the project is not yet available in the Google Play store or the Apple app store.

The distribution paths reflect the same split. Desktop installs through the Microsoft Store, with a sideload link in the README's badge row, and a Chocolatey package that the README is careful to label as not maintained by the author.

Installing on Windows, and the winget route the README prefers

For Windows, the README says to install safely via the Microsoft Store, and then gives a command line option it recommends for people who prefer it.

winget install 9P9D81GLH89Q

The identifier in that command is the Microsoft Store product id, which is why it looks like a random string rather than a package name.

There is also a Chocolatey package, with the README marking it as not maintained by the author in the same way it labels the community package elsewhere in the page.

choco install 2fast

The distinction matters. The Store version is signed and distributed by Microsoft, which is the safer route for an application that holds your second factors, and the community package is a convenience with a different maintenance owner.

If you want to run the current release candidates rather than the store build, the releases page has them, and the recent release tags show the shape of the current cycle: v1.5.2-preview2 in August 2026, v1.5.2-rc1 in October, and v1.5.2-rc2 on the same day as the last push. So the 1.5.2 line is in release candidate form rather than shipped, and the store build is likely still on the previous stable line.

The repository is not archived and the last push was on 2026-10-18, so the project is being worked on.

Building from source needs Visual Studio 2026 and a set of prerequisites

The Getting Started section is for contributors, and the prerequisite list is long enough to be worth reading before you start.

Visual Studio 2026 is required, with the Mobile development with .NET package selected during installation, and .NET Multi-Platform App UI development listed. For the universal Windows application you need Windows 10 version 1809, the October 2018 update, or later, plus the latest Windows 11 SDK. For the Android application you need Android version 10.0 or later, and you are told to remember to trust third party apps by enabling that in the Android developer settings if you want to build from source.

Then there is the Windows Store Service SDK for the UWP target only, the Uno platform add-in, and a Nuget source for Windows Toolkit Labs, given as a URL.

https://pkgs.dev.azure.com/dotnet/CommunityToolkit/_packaging/CommunityToolkit-Labs/nuget/v3/index.json

The build itself is four steps. You clone the repository with all its submodules.

git clone --recurse-submodules https://github.com/2fast-team/2fast.git

You open the .slnx file with Visual Studio, where the dependencies are loaded automatically, and the README points at the uno-check documentation if the Uno project has dependency problems. Then you start working and debugging, remembering to select the correct start project and platform before running, for example x64 and UWP for the universal Windows application.

The submodules flag is the detail that saves an afternoon. The repository has a .gitmodules file, and the dependencies come from the UNOversalTemplate, so a shallow clone without the submodules leaves you with a project that opens but does not build.

The privacy and telemetry position, and what the wiki covers

The Privacy section is short and specific. For UWP, the app does not use any of its own telemetry functions apart from the standardised telemetry functions by Microsoft, which it lists as crashes, install from which country, versions in use and custom events.

That is a narrower claim than most apps make, and it is worth reading carefully rather than as marketing. It says the app itself does not collect anything, while the platform underneath it does, under Microsoft's own policy. Whether that is acceptable depends on your threat model, and for a second factor application the question of what leaves the device is a fair one to ask before you migrate your accounts in.

The localisation and metadata picture is consistent with the rest of the design. The app needs no account and no network connection except for WebDAV, and the WebDAV server is one you choose, for example ownCloud or Nextcloud.

The wiki is where the operational detail lives, and the README points to it for the full picture. It is also where the account list of third party libraries, images and information with their source and licence lives, in the Dependencies of the app section of every installation.

The trademark and icon position is spelled out at the end of the licence section. The current key icon logo is by freepik on flaticon, and the project notes it is made in Germany. The application is a Microsoft Store app and was a finalist in the Store App Awards, which is the sort of external recognition that says the packaging and onboarding were reviewed by someone other than the author.

Where 2fast is the wrong choice

Three cases, and only one of them is about the software.

The first is mobile. The Android, iOS, Linux and macOS applications are listed as under development, the project is not in the Google Play store or the Apple app store, and the mobile builds are the ones that carry a fee. If you want an authenticator on your phone with a normal store install, this is not it yet, and the desktop app does not solve that problem.

The second is the single file design, and it is a design rather than a defect. One encrypted file is what makes backup trivial and the file shareable, and it is also the entire security boundary. There is no second copy in a cloud account, no device binding, and no separate recovery key, because the file plus the password is the credential. That is a good property for a backup and a concentrating property for a risk. The README frames sharing the file with colleagues and friends as a feature, and it is, but it also means the file is worth encrypting well and worth backing up in more than one place.

The third is the platform and the build. The desktop application targets Windows 10 version 1809 and later, and the whole project is a Visual Studio 2026, .NET and Uno build. The cross platform work is genuinely under way, but if you want a Linux authenticator you can build today without a Windows toolchain and an Uno add-in, that is not this project yet.

One smaller caveat about provenance: the TOTP implementation comes from Otp.NET and the barcode scanning from ZXing.Net.Uno, so the correctness of the two most security relevant pieces rests on those libraries rather than on this project.

Editorial conclusion

Adopt 2fast if you want an authenticator whose entire state is a single encrypted file you control, and you are on Windows 10 version 1809 or later with a .NET development environment if you intend to build it. Do not adopt it if you need a mobile authenticator today, since the Android, iOS, Linux and macOS builds are still under development, and note that the mobile releases are fee based while the desktop builds are free. Before you migrate your accounts in, decide where the encrypted file will live, since that file is the only thing standing between a lost device and a lost second factor.

Frequently asked questions

Official sources

1. 2fast-team/2fast on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases