Account security · LOGIN KEYS
Passkey or Authenticator App: They Do Not Guard the Same Doors
The security centre now offers two things. One is the authenticator you have used for years, throwing a fresh six digits every thirty seconds. The other is a passkey, advertised as signing in with no password and no code at all. The natural conclusion is that the new one replaces the old one.
Acting on that leaves the account weaker than before you started. Not because one technology is worse, but because the two are allowed to guard different doors — Gate's own documentation says the authenticator is used for sign-in, withdrawal, password changes and security settings, while a passkey is currently usable in the sign-in scenario. This piece lines up the mechanism, the coverage gap, the device requirements, the storage choice and the recovery routes, then closes with who should run what. The reasoning holds on any platform offering passkeys; the specific requirements are Gate's current ones.
They stop different attacks
Get the mechanism straight and the rest of the decision follows.
An authenticator works from a shared secret. At setup the platform hands your app a seed; the app combines that seed with the current time to produce six digits, the platform runs the same calculation, and matching values let you through. What it defends against is a leaked password — knowing the password is not enough without the phone.
What it does not stop is live phishing. A fake site forwards whatever you type — password and six digits alike — to the real site while the code is still valid. You believe you are signing in; you are signing the attacker in. These sites have become very good, often differing from the real domain by a single character.
A passkey works differently. Creating one generates a key pair on the device; the private half stays in the device's secure storage and never leaves, and the platform only ever receives the public half. To sign in, the platform sends a random challenge and the device signs it. The signature is bound to the site's domain, so a signature produced for a lookalike domain is worthless at the real one. Copying the entire page gets an attacker nothing usable.
The difference that actually decides it: coverage
Most comparisons stop at the previous section, which leaves readers with the wrong conclusion: passkeys are stronger, so swap. The table below is what should actually drive your setup.
| Door | Authenticator | Passkey |
|---|---|---|
| Sign-in | Used | Used |
| Withdrawal | Used | Not listed in the official documentation |
| Changing the login password | Used | Not listed in the official documentation |
| Changing security settings | Used | Not listed in the official documentation |
Gate's guide to binding and unbinding the authenticator states that the authenticator is used for sign-in, withdrawal, password changes and security settings. Its passkey overview states that a passkey is currently usable in the sign-in scenario.
So these two stack; they do not substitute. The passkey converts the step you perform most often, and the one phishing targets hardest, into something phishing cannot relay. The authenticator goes on guarding the steps that actually move money. Turning it off returns the withdrawal door to a state where a password alone can change things.
What Gate requires in practice
A few prerequisites are worth checking before you start, so you do not get halfway and discover the device does not qualify:
- Two verification methods first. The documentation requires at least two security verification methods bound before you can create a passkey — which itself tells you how the platform positions the feature: added on top of what you already have, not a way to clear it out.
- Mobile: iOS 16.0 or later, or Android 9.0 or later.
- Desktop: Windows 10 or macOS Ventura and above, with Chrome 109, Safari 16 or Edge 109 and above.
- A FIDO2-compatible USB security key can also be used alongside the mobile device.
In the app the path runs from the avatar into profile and settings, then the security centre and verification methods; on the web, hover the avatar, open Security and enable the passkey entry. Interfaces get redesigned and menu names change, so treat what is on your screen as authoritative. We checked this against Gate's published help documentation on 2026-09-03.
Where it lives decides whether it survives a new phone
When you create a passkey the system asks where to keep it. The choice looks unimportant at the time and matters enormously the day you change devices.
| Storage | On a new device | Suits |
|---|---|---|
| iCloud Keychain (Apple devices) | Syncs across with the Apple account | People whose phone and laptop are both Apple |
| Google Password Manager | The documentation notes it syncs automatically with the Google account | Android-first users |
| A browser's local profile | The documentation states it is saved only on that device | People who only ever sign in from one machine |
| USB or NFC security key | The key is in your pocket and works anywhere | People willing to carry hardware for security |
Row three is where people get hurt. It is easy to click through on a desktop and end up with a passkey stored in that browser profile, which ceases to exist when you replace the machine or reinstall the system. If you are only going to create one passkey, do not pick the device-only option.
What losing each one looks like
The two failure modes are completely different, and knowing that in advance saves a very stressful day.
Losing the passkey. If the authenticator still works, verify with it, delete the old passkey and add a new one. Note the documented condition: deleting a passkey requires confirmation through a passkey or two-factor verification — meaning you must still hold something that proves who you are. That is the concrete reason not to keep only one key.
Losing the authenticator. A longer road. Per Gate's current documentation, if you can still sign in you can run a security-item reset from the security centre; the request is reviewed within 24 hours and the outcome arrives by email. If you cannot sign in, the web interface cannot start the request at all — you submit it from the app by tapping the unable-to-verify option on the code screen. We cover how the three cases split in recovering a lost authenticator.
One thing worth doing right now: when you bind an authenticator, write down or screenshot the setup secret. The documentation flags this in its own notes, because people with a backup can rebuild it themselves while people without one wait for a review.
Which setup fits you
Putting it together, most people land in one of three places:
- You buy occasionally and mostly leave it alone. The authenticator is not optional; the passkey is. Your exposure is concentrated at the withdrawal door, and that door belongs to the authenticator.
- You sign in often and withdraw often. Run both. The passkey blocks phishing at sign-in, the authenticator guards the money-moving actions, and a withdrawal address whitelist on top closes most of the common attack paths.
- Mixed devices, frequent upgrades, or a balance that would hurt to lose. Run both, choose a syncing storage location or a hardware security key, and keep at least two keys on different media. The test is simple: assume the phone in your hand is destroyed right now — can you still get in?
Three things not to do
- Do not switch the old one off because the new one is on. This is the single thing this article exists to prevent. Different coverage means removing the authenticator removes the lock from withdrawals and settings.
- Do not create exactly one passkey and leave it in a browser profile. Replacing the computer, reinstalling the system or clearing browser data each ends it, and both deleting and recreating require another verification method. Keep two, on different media.
- Do not read repeated code rejections as a compromise. The documented first step is checking the device clock. Time-based codes drift out of sync with the phone's clock. Turn on automatic time sync before assuming anything worse.
Editorial check
What our editors checked
Reading both official documents side by side, the sentence most often skipped is the important one: a passkey is currently usable in the sign-in scenario, while the authenticator is used for sign-in, withdrawal, password changes and security settings. Comparison articles online tend to cover phishing resistance and stop, which leaves readers concluding they can swap — the one action they should not take. Device versions, browser versions and storage options all move with product updates, so treat the page in front of you as current. To order the whole security setup by priority, continue with which settings to switch on first; if the authenticator is already gone, go straight to recovering a lost authenticator.