Is it safe to screenshot your 2FA QR code?

There is a thought that arrives at one exact moment for almost everybody: the setup screen is open, the QR code is on it, the service is about to take it away forever, and I should just screenshot this.

Or you are not on a setup screen at all. You did that months ago, several times, and you have just worked out that your camera roll has four of them in it, somewhere between a parking receipt and a photo of your cat.

Both versions are the same question, and the pages ranking for it do not answer it: one lists screenshotting as a bullet in a generic set of backup ideas, one recommends it beside printing and a USB stick, and one is about whether a screenshot of a QR code still scans at all. None of them tells you what that QR code contains — which is the entire answer.

So this page unpacks the QR, says what a screenshot of it becomes once a photo library gets hold of it, ranks the places a copy may legitimately live, and gives you a triage for the screenshots already there.

The short answer

• The QR is not a link to your account. It is an otpauth:// URI and it carries the secret itself, in plain text, as a base32 string.
• That secret is a bearer credential with no expiry. Anything holding it can produce valid codes for that account indefinitely, from anywhere, with no network connection.
• It is not the same thing as your backup codes. Those are single-use and revocable. This is the key they were a fallback for.
• A screenshot in your camera roll is a copy of that key in a library that syncs, keeps deleted items for 30 days, and makes the text inside pictures searchable — including to anything else with photo-library access.
• Re-scanning the same QR on another device is a silent clone. The service cannot tell the devices apart, cannot list them, and cannot revoke one.
• The only way to kill a leaked secret is to re-enrol at the service, which issues a new one and instantly breaks every device still holding the old one. Deleting the picture revokes nothing.
• For ten minutes, offline, deliberately deleted afterwards: a defensible risk. As a permanent entry in a synced photo library: no, and it is not close.
• KeyNesta holds TOTP and HOTP only — no passkeys, no security keys. And because sync is zero-knowledge, if you lose your passphrase we cannot recover your vault for you.

What that QR code actually is

The QR is a transport. It is a picture of a URI, and the URI is where everything lives — Google's otpauth:// scheme, which every mainstream authenticator reads: otpauth://TYPE/LABEL?PARAMETERS (Key Uri Format). Point any QR reader at one and the whole thing is plain text. What it carries:

Read the table from the top and notice the shape of the problem. Five of those fields describe how to compute a code and what to call the entry. One of them is the thing that makes the codes valid, and the picture in your camera roll contains it along with the name of the account it opens and the email address it belongs to. A screenshot of a 2FA QR code is not a hint about a credential. It is the credential, plus a helpful label saying which door it is for.

Two standards are worth reading side by side here, because together they say what this secret is for and how seriously everyone else is expected to treat it.

RFC 6238, the TOTP standard, states the arrangement as a requirement: "The prover and verifier MUST either share the same secret or the knowledge of a secret transformation to generate a shared secret" (RFC 6238 §3). Your app holds one copy, the service the other, and after setup nothing is transmitted — which is why your authenticator works on a plane. RFC 4226, which TOTP builds on, sizes it: "The length of the shared secret MUST be at least 128 bits. This document RECOMMENDs a shared secret length of 160 bits" (RFC 4226). Nobody guesses a 160-bit key. It only ever leaves by being copied.

Both RFCs also tell the service how to hold its half, and the contrast is the point. RFC 6238: "The key store MUST be in a secure area", and "We also RECOMMEND storing the keys securely in the validation system, and, more specifically, encrypting them using tamper-resistant hardware encryption and exposing them only when required". Tamper-resistant hardware encryption on one side of the arrangement. A JPEG on the other.

It is not your backup codes, and that distinction is the whole risk

People file the QR screenshot mentally where they file the sheet of recovery codes, and it does not belong there. Where to store your 2FA backup codes is the right page for those; this is why they are different objects.

That bottom-right cell is what the backup listicles leave out. No consumer service has a "rotate my TOTP secret" control, because from its side there is nothing to rotate: the secret was issued once, at enrolment, and the only way to replace it is to run enrolment again. NIST names the failure mode exactly — its authenticator threat table lists Duplication, "The subscriber's authenticator has been copied with or without their knowledge", and the mitigation is about design rather than habits: "Use authenticators from which it is difficult to extract and duplicate long-term authentication secrets" (NIST SP 800-63B-4).

A screenshot is the opposite of difficult to extract. It is the secret, already extracted, pre-formatted for the next scanner.

What a screenshot becomes once your photo library has it

This is the section the pages ranking for this query skip entirely, and it is the one that decides the answer. A camera roll is not a drawer. It is a synchronised, indexed, machine-readable, widely-shared database with a 30-day undo, and every one of those properties works against you here.

It leaves the phone, and Apple holds the keys. Apple's own data security table puts Photos under standard data protection — encrypted "in transit & on server", with Apple retaining the keys — alongside iCloud Backup and iCloud Drive. The categories that are always end-to-end encrypted include Passwords and Keychain, Health and Messages. Photos is not among them. It becomes end-to-end encrypted only if you switch on Advanced Data Protection, an "optional setting" after which "your trusted devices retain sole access to the encryption keys for the majority of your iCloud data" (Apple). Most people have never opened that screen.

It lands on every device you own, including the ones you forgot. "Changes you make on one device change on your other devices too", which includes the old iPad in a drawer, the family Mac, and anything signed in to that Apple Account (Apple).

Its text is searchable, which cuts both ways. Google Photos documents exact-text matching inside pictures: "You can use quotation marks in your search if you want to find exact-text matches in filenames, camera models, captions, or text within photos" (Google). On iPhone, Live Text "recognizes information within your photos, videos, and images you find online. That means you can make a call, send an email, or look up directions with a tap" (Apple). That is genuinely useful in the triage below — it is how you find your own screenshots. It also means the issuer name and the email address printed under the QR are indexed strings, and finding the interesting pictures in a library of 40,000 is now a search box rather than an afternoon.

Deleting it does not delete it. On iPhone, "If you delete something accidentally, you can recover it in the Recently Deleted folder for 30 days" (Apple). Google Photos documents the same shape: "Photos and videos that you delete will stay in your trash for 30 days before they are permanently deleted" (Google). A deleted screenshot is a screenshot in a different album for a month.

Other software can read it. Photo-library access is one of the most freely granted permissions on both platforms: every editor, collage maker, scanner, cloud drive and social app asks, and most people say yes. A screenshot of a QR code is a machine-readable credential sitting in a directory any of them can enumerate. Then add the places photos go on purpose — shared albums, a Dropbox or OneDrive camera-upload folder, the chat thread where you sent the QR to your own laptop "just to scan it".

None of that is an attack. It is the documented behaviour of a product built to make sure you never lose a picture, which is the exact opposite of what you want around a key.

Re-scanning the same QR is a silent clone

The reason people keep the screenshot is usually sound: they want the codes on a second device, or they expect to need them after a phone upgrade. It is worth being precise about what re-scanning does, because it is not "registering another device".

Go back to RFC 6238 §3 and notice what is missing from it: there is no device in the arrangement. A second phone holding the same secret is not a second registered authenticator; it is one credential being computed in a second place. So:

• The service cannot tell them apart. Two devices producing the same six digits are indistinguishable from one device, because valid is all the verifier can see.
• There is no list to audit and no device to remove. The sign-in record proves a correct code arrived. It cannot say which copy computed it.
• Every copy stays live until you rotate. The screenshot, the printout, the phone you sold last year: each still generates accepted codes, and nothing on the account expires them.

Which brings us to the one control that does exist, and the warning that goes with it. Pressing Edit, Change or Set up again on a service's 2FA settings does not re-show you the secret you already have. It issues a new one, and the moment you confirm the new enrolment every device holding the old secret is producing numbers the service no longer accepts — including the phone in your pocket. That is the kill switch for a leaked QR, and it is a loaded one: have the account's backup codes in front of you before you touch it. How to use an authenticator app on two devices walks the whole sequence, including the ordering that keeps you out of your own recovery flow. It is also the single most common reason a code is suddenly refused months later, which is why a retired entry sits near the top of 2FA code not working: causes and fixes, in order.

The better answer, where it exists, is a service that treats MFA as a list you can add to. AWS is the clearest documented case: root and IAM users "can register up to eight MFA devices of any type", and a lost device "should be disassociated from the IAM principal with which it is associated" (AWS IAM). Two enrolments means two secrets, each revocable alone — strictly better than any copy. Check for it before reaching for the screenshot: a row with an Add button beside it means you have it, a single setting offering Edit means you do not.

Where a copy may legitimately live, ranked

Best to worst, and the honest version of this list is that the top entry is not a copy at all.

1. No copy — a vault you can back up instead. The reason to keep the QR is almost always that your authenticator cannot export or sync. Fix that instead, and the whole question disappears: an encrypted vault backup carries every entry as ciphertext, with the key in your head. One protected file beats one plaintext picture per account.
2. A second enrolment at the service, where the service supports it. A separate secret, independently revocable, visible as its own row. Not a copy in any sense.
3. An encrypted export from your authenticator. Ciphertext at rest, passphrase never on a server. Same category as the vault backup above, one step more manual. A backup you cannot decrypt is not a backup, so test the restore once while nothing is on fire.
4. Printed on paper, unlabelled, in a sealed envelope in a rated box. Paper cannot be read remotely or exfiltrated by malware. Two details matter: the word fireproof means nothing, while a UL 72 class means something — the ratings and the freezer-bag trick are in where to store your 2FA backup codes — and write the issuer on the envelope, not next to the QR.
5. An encrypted container on a device you control — a password-manager secure note or an encrypted disk image. Workable, with one caveat worth taking seriously: if that manager also holds the password for the same account, a single unlock is now a complete login. Should your 2FA codes live in your password manager? argues both sides.
6. A screenshot you delete within the minute, taken with the understanding that "delete" means delete, then empty Recently Deleted. This is the honest version of the convenience move — scan both devices now, remove both copies, done.
7. A screenshot that stays in a synced photo library. Everything in the section above. This is the thing to stop doing.
8. Emailed, messaged, or in a shared folder or shared album. The secret is now in somebody else's infrastructure and, with a shared album, in somebody else's library. Email is worse than it looks: your inbox is the account most of your other accounts recover through.

One extra rule for anyone who found this page while moving phones. An export QR from an authenticator is not one secret — Google Authenticator's Transfer codes screen draws QRs that carry every entry you selected (Google). Screenshotting that to scan later puts your whole set in the camera roll at once, and there is no re-enrolment button that fixes a whole set in one go.

Triage: the screenshots already in your Photos

If you are here because the pictures already exist, work through this in order. It takes about twenty minutes and most of it is bookkeeping.

1. Find them. Use the text search the previous section described — it was built for exactly this. Search your library for the issuer names you would expect ("Google", "GitHub", "Coinbase", "Microsoft"), for otpauth, and for the words that appear on setup screens: authenticator, two-factor, scan this, verification. Then open the Screenshots album and scroll the weeks around any account you remember setting up.
2. Identify what each one opens. The label under the QR usually names the service and your account. Where the picture is cropped or unreadable, treat it as an unknown secret for an unknown account — which, for the decision in step 5, counts as the worst case rather than the best.
3. Delete them, then empty the holding area. Deleting is not finished until Recently Deleted (iPhone) or Trash (Google Photos) is empty, because both hold items for 30 days and both still sync. On iPhone, Recently Deleted sits behind Face ID or your passcode.
4. Go after the other copies. This is where it usually goes wrong, roughly in order of how often each is missed: other devices signed in to the same photo account; a laptop running the desktop Photos app or Google Drive sync; a Dropbox or OneDrive camera uploads folder; shared albums; the chat thread or email you used to send the QR to yourself; a device backup taken while the screenshot was still there; and a work account, if the picture ever touched a managed device. Each is an independent copy with its own deletion.
5. Decide whether to rotate, and be honest about it. Deletion reduces future exposure and revokes nothing — anything that already read the picture still holds a working key. Rotate the secret at the service if the screenshot was ever somewhere you do not fully control: a shared or family device, a work account, a messaging service, a cloud account since caught in a breach, a phone you sold or returned. If it lived only in your own library on your own devices, with 2FA on that cloud account itself, deleting it and moving on is a reasonable call. Choosing not to rotate is fine. Not noticing that you made a choice is not.
6. If you do rotate, do it in the right order. Backup codes visible first, stay signed in somewhere, start the new enrolment, scan it on every device you want while the QR is on screen, confirm one code, then delete the old entries. Then regenerate that account's backup codes too — if the screenshot came off a setup screen, the codes beside it are probably in the library as well.
7. Close the loop that made you screenshot it. If the reason was "I will need this on the laptop", the fix is an authenticator that exists in both places. If it was "I will need this for my next phone", the fix is a backup you have tested. Otherwise you will be back here after the next upgrade — and if the app is already gone, what a reinstall actually restores is the page for that.

So, is it safe to screenshot 2FA QR codes?

The question only looks binary. Three things decide it, and all three are about the container rather than the picture.

• How long it exists. Taken to scan a second device, then deleted from the library and from Recently Deleted inside five minutes: a short-lived copy of a key on hardware you are holding. That is an ordinary risk, and a far better plan than pressing Edit on a live account with no backup codes to hand.
• Where it lands. The same screenshot left in a synced library is a permanent, indexed, machine-readable copy in a cloud account Apple or Google can decrypt, mirrored onto every device you own. Nothing having gone wrong yet is not evidence that it is working.
• Whether anything else can read it. Shared albums, camera-upload folders, chat threads, work accounts and device backups each turn one decision into several copies with separate lifetimes. If you cannot name every place a picture goes, you cannot say how exposed the key is.

And the asymmetry that should settle it: every other security object you own has a revocation story. A password can be changed, a session killed, a backup code spent, an API token deleted. A TOTP secret has none of that. Treating it as the one object on the list with no undo is not paranoia — it is reading the standard it came from.

Where KeyNesta fits, and what we cannot do

Stated plainly, because this page is about containers and we are one.

• A second device is a sign-in, not a second scan. Your vault exists on your phone and in the web app. You sign in on the second device, unlock with your passphrase, and the entries are there — no QR to keep, no re-enrolment, no visit to each service. That is the whole reason the screenshot habit exists, removed rather than managed.
• Sync is zero-knowledge, and optional. Entries are encrypted on the device before they leave. The server holds ciphertext, object ids and version numbers, and no key that opens any of it. Prefer no server at all? 2FA backup and sync covers the encrypted backup file instead.
• Devices are a list you can revoke. You can see every device on the sync account and revoke any of them — the per-device control a duplicated secret cannot offer. It applies to your vault, not to secrets another app is holding.
• We cannot recover a vault for you. Nobody here can reset your passphrase, and with no sync and no backup file there is nothing on our side to restore. That is a property of the design, not a support policy, and it is the cost of a breach of our servers being uninteresting. What zero-knowledge costs you is that trade in full.
• TOTP and HOTP only — no passkeys, no security keys. The features page names passkeys among what is not built, and an authenticator app of any kind is not a FIDO authenticator. If what you want is a credential that cannot be screenshotted because it never leaves the hardware, that is a security key, and passkeys are the other half of that answer. We do not substitute for either.

If you want the arithmetic underneath all of this — how a clock and a key become six digits, and what the counter field is doing in that table — TOTP vs HOTP has it.

Takeaway

It feels like a question about tidiness and it is actually a question about what you are holding: a 160-bit key, the name of the service it opens and the account it belongs to, in plain text, in a format built to be read by a machine at a glance.

So scan it now rather than later. If you must keep a copy for five minutes, keep it for five minutes and empty Recently Deleted. If you need one for next year, make it an encrypted backup or a second enrolment, not a picture. And if the screenshots already exist, spend twenty minutes on the triage above — find them, delete them, chase the other copies, and decide consciously whether to rotate.

The difference between a non-event and a bad week was never the screenshot. It was whether the key had somewhere to end up.