A new printer comes out of the box, shows a square on its little display, and four seconds after the phone app reads it the printer is on the office network. Nobody typed the wifi password. The code did not contain the wifi password either, which is the difference between a pairing channel and a printed secret.
QR codes turn up in pairing flows for a simple reason: one device has a screen and no keyboard, and the other has a camera and an owner already signed in somewhere. The square is a short conversation between those two facts.
Three shapes, and they are not interchangeable
The first shape is a device showing a code that a phone scans. A TV app waiting to be signed in, a printer in setup mode, a camera's provisioning screen. The device is asking to be claimed, and the code is a request identifier with a lifetime.
The second is a code printed on the device or its packaging. Smart bulbs, cameras, some routers and plenty of consumer hardware carry one moulded into the base or stuck underneath. Permanent, factory issued, and that single difference changes how it has to be defended.
The third is the phone showing a code that the device reads. Less common, because it needs a camera on the far side, but it exists: a handheld scanner reading network credentials off a phone screen is this shape.
Which shape you are in tells you where the secret lives and how long it lives, and most mistakes here come from treating one shape as another.
What the code actually carries
Rarely a password. In the first shape it is usually a short-lived token: an identifier for a pending claim held on a server, not a credential usable on its own. The phone holds the real credential and approves the pending request. How scan-to-sign-in works step by step sets out that handshake, and the same three-party structure underlies device claiming.
The second shape is often a device identity plus a public key. Wi-Fi Easy Connect, the provisioning mechanism the Wi-Fi Alliance defined for this job, puts a URI in the code carrying the device's public bootstrapping key and a channel hint. The phone reads it, establishes cryptographically that it is talking to that specific device, then hands over network credentials over the air. The password is never in the symbol, so photographing the label does not give away the network. What it gives away is the ability to attempt to provision that device, which is why hardware normally accepts provisioning only in a particular state. Android has supported this since Android 10; device-side support varies by manufacturer.
The third shape is where the code really is the secret. A plain wifi code carries the network name, the security type and the password as readable text, so anyone who photographs it has the network. The wifi code format covers what sits inside one; it is a printed password rather than a pairing token, however much it resembles the codes above.
The phone is the trusted party, and that is the design
The device knows nothing about you. Your phone does, because it holds a credential for the account or is already on the network. Pairing is the phone lending its trust to something with none of its own, and the server in the middle believes the phone because its credential is valid.
There is no second check on whether you meant it: if the phone approves, the answer is yes. That is why the lock screen on your phone is part of the security of every device you have ever paired, and why an app that asks for a fingerprint before confirming a pairing is doing something real. Read from the other side, a phone left open in someone else's hand is an approval machine.
Expiry is what stops a replay
Between the moment a code appears and the moment somebody approves it, an unclaimed pending request is sitting on a server. Anyone who obtains that identifier and gets an approval attached to it holds the result. The window is the risk, so the token has a lifetime, usually a minute or two, and the screen refreshes it rather than leaving one up.
A code that never changes has no such window. It has a permanent one. That is where the printed-label case gets uncomfortable: a code moulded into the base of a bulb cannot expire and cannot be rotated, so its defence is not secrecy but state. Most devices accept pairing only while unclaimed, or while a physical button is held, which makes the label useless once the hardware belongs to somebody. That is a design decision you are trusting, not a property of the code, and it matters wherever the pairing secret is also the reset path: a resale listing photographed from the wrong angle has published it.
Anyone building this should treat the sequence as expiry plus single use plus a state machine that cannot be raced, which is laid out in building scan-to-sign-in yourself. The related case of a secret meant to be permanent runs through the code in an authenticator app.
What goes wrong
A pairing code photographed off a shared screen is the common one. A code on a projector, on a lobby television, or pasted into a support ticket has been handed to everyone who can see it, and only the expiry is protecting the account. If one has appeared in a ticket, a chat thread or a screen share, cancel it and start again rather than reasoning about who saw it.
A code left somewhere public is the same problem with more time attached. A kiosk showing its claim code overnight, a shared-office printer sitting in setup mode for a week, a sticker on the outside of a device in a corridor. Anything left in pairing mode in public is waiting to be claimed by whoever arrives first, and the owner then finds it already paired to somebody.
Then the failure that is not a security problem at all: a television too dim to read. Panels run dark in a lit room, the code is often rendered small inside an interface scaled up to a large screen, and the sofa is three metres away. Add a window reflection and there is nothing for a camera to work with. Why codes fail when read off a screen covers the mechanics. For whoever builds the screen the fixes are dull and effective: high contrast, never inverted, a full quiet zone, larger than the design wanted, and the short code printed underneath so a typing fallback exists.
What to do as the person pairing
Only pair a device you are standing in front of, and only after you started the process yourself. Never scan a pairing or sign-in code that arrived in a message, an email or a support conversation, whatever reason accompanies it; the reason is the only part an attacker has to invent. Read the confirmation screen before tapping, because the device name on it is the one piece of the handshake a human verifies.
The housekeeping is duller, and nobody does it until something goes wrong. Most accounts list paired devices and let you remove them, so drop what you no longer own, and unpair hardware before selling it. Treat an unexpected pairing prompt as an alarm rather than a glitch: something asked to be let in, and it was not you. The wider security picture covers the neighbouring tricks.
Next time a device shows you a code, read what the confirmation screen names before you tap. That name, and the fact that you are holding both objects, is the entire verification on offer.