You have a deadline. A source needs to send documents before a procurement hearing closes. A colleague is about to hand over credentials before a patch window opens. You are both on Signal, and you want to know that the conversation is the one you think it is. The safety number is the tool for that, and comparing it in person takes less time than reading this paragraph aloud.
But the safety number is also the most misunderstood screen in the app. People treat a match as proof of identity and a change as proof of an attack. Neither is true. This article walks through what the number represents, how to compare it face to face, and how to read a change without either panicking or shrugging it off.
What the safety number actually is
Signal’s own documentation describes the safety number as a per-conversation value, not a per-user one. Each party sees a single string of numbers for the conversation, and comparing them is the verification step. Signal introduced this design in 2016 specifically because the older per-user fingerprint model confused people and produced false positives and false negatives in user studies (Signal, “Safety number updates,” 17 November 2016).
Underneath, the number is derived from the identity keys that each side uses in the key agreement. Signal’s X3DH specification states that parties may compare their identity public keys through an authenticated channel, “for example, they may compare public key fingerprints manually, or by scanning a QR code,” and that the methods for doing so are outside the specification’s scope (Signal, X3DH Key Agreement Protocol, Revision 1, §4.1). The same section is blunt about the consequence of skipping this step: “If authentication is not performed, the parties receive no cryptographic guarantee as to who they are communicating with.”
That sentence is the whole argument for verification. Encryption protects the content of messages in transit. It does not, by itself, tell you that the key your app received for your contact belongs to your contact rather than to someone who substituted a key along the way. The safety number comparison is the out-of-band check that closes that gap.
Why in-person comparison is the strongest option
Any comparison over a channel that could itself be compromised inherits that channel’s weaknesses. Comparing numbers over the same Signal thread is circular. Comparing them over email assumes the email account is the right person’s. Comparing them in person removes the middleman from the comparison itself: you are looking at the other person’s screen, or scanning their code, with your own eyes.
Signal’s 2016 post describes the in-person flow as a single QR code scan rather than the older two-scan dance: “for in-person comparisons, there is only a single QR code to scan, rather than each party having to both scan and be scanned by the other as before” (Signal, 2016). The post also notes that the QR code was changed to contain only the safety numbers themselves, after users published screenshots that embedded phone numbers.
One caveat on procedure: the exact menu labels in the current app are not something this article can assert from a primary source. Signal’s public support article on safety numbers was not retrievable for this piece, and the 2016 post describes an older interface. The reliable description is the one Signal’s own specification gives: open the conversation, view the safety number, and compare it by scanning the QR code or reading the digits aloud. If the labels on your screen differ from what you remember, follow what the app shows; the cryptographic operation is the same.
A practical in-person procedure
- Open the right conversation. Confirm on both devices that you are looking at the same contact thread. This sounds trivial; it is the most common source of error.
- Open the safety number screen from the conversation’s contact or conversation info.
- Compare. Either scan the other person’s QR code with your camera from within that screen, or read the digit groups aloud and have the other person confirm each group. Do not read from a screenshot sent over Signal; that defeats the purpose.
- Mark the contact as verified if the app offers that control. This is what lets Signal warn you later if the number changes.
- Write down the date in whatever log your team keeps. Verification is a recurring practice, not a ceremony you perform once and forget.
Remote verification, and the mistake almost everyone makes
If you cannot meet, use a channel you already trust for that person: an email thread you have used before, a phone call to a number you already had, a video call where you can see their face. Send the safety number through that channel and compare.
Here is the trap. Both parties see the same safety number for the conversation. If you send yours first, the other person can simply read it back to you, and you will have verified nothing. The person doing the verifying should wait for the other party to send the number independently through the trusted channel, then compare it to what their own screen shows. A third-party guide makes this point directly: “Both parties in a Signal conversation have the same Safety Number, so if you send it first, the other person can simply read it back to you” (Techlore, “How to Verify Signal Safety Numbers”).
This is a recommendation about procedure, not a claim from Signal’s documentation. It follows from the fact that the number is symmetric. Treat it as a rule of thumb: the party with the higher stakes in the conversation should be the one receiving the number, not sending it.
What a changed safety number means
Signal’s 2016 post is explicit that keys change routinely: “People’s Signal keys change every time they get a new phone or reinstall the app” (Signal, 2016). The same post describes the introduction of an advisory mode in which a key change displays a notice in the conversation history but does not block messages, with manual approval available as an option. That was the state of the rollout in 2016; the current default is not something this article can assert without a current official support page.
What follows from the documented behavior is a simple rule: a changed safety number is a prompt to re-verify, not a conclusion of compromise. The most common causes are a new device, a reinstall, or a SIM transfer. A third-party guide puts it plainly: “This doesn’t automatically mean something is wrong. Most Safety Number changes are completely innocent: your contact got a new phone. But it does mean you should re-verify before continuing any sensitive conversation” (Techlore). An AboutSignal knowledge base entry makes the same point and adds a useful qualifier: frequent or unexpected changes may indicate something is going on (AboutSignal).
So the correct response to a change is neither panic nor dismissal. It is a short, calm sequence:
- Pause sensitive traffic in that conversation. Do not send the document, the credential, or the source’s identity until you have re-verified.
- Contact the person through a separate channel you already trust, and ask whether they changed devices, reinstalled, or transferred a SIM.
- Re-verify using the in-person or remote procedure above.
- If the explanation does not fit — the person says nothing changed, or the change recurs without explanation — treat the conversation as untrusted until you can verify in person or through a channel you are certain of.
That last step is a judgment call, not a documented Signal behavior. It is the reasonable response when the documented explanation (device change) does not match what the person tells you.
What verification does not prove
This is the part that matters most for journalists, activists, and small-business owners who are used to thinking in terms of identity.
A matching safety number does not confirm that the person you are talking to is who they claim to be in the real world. It confirms that the Signal conversation you are in is cryptographically tied to the same identity as the person you verified through the other channel. The trust in the human still has to come from somewhere else. As the Techlore guide puts it: “Matching Safety Numbers doesn’t prove the person emailing me is who they claim to be… What it does prove is that the Signal conversation I’m in is cryptographically tied to the same identity as whoever sent that email.”
Signal’s X3DH specification adds a related limit. Authentication as described in §4.1 “does not necessarily prevent an ‘identity misbinding’ or ‘unknown key share’ attack,” in which an attacker presents one person’s key as their own and forwards messages (X3DH, §4.8). Including more identifying information in the associated data makes this harder, but the specification is clear that it does not eliminate the risk.
Verification also does not protect against a compromised device. If malware is reading your screen, the safety number match is irrelevant. It does not protect against a coerced unlock. It does not tell you whether the person on the other end is acting under duress. Those are threat-model questions that a number comparison cannot answer.
A pre-switch checklist for small teams
The most common way a safety number change becomes a crisis is that nobody warned anyone. A five-minute routine before a device switch prevents most of it. This checklist is a recommendation, not a documented Signal procedure, but each step follows from the documented behavior above.
- Before switching: verify safety numbers with the contacts who matter most, and note the date.
- Before switching: tell those contacts, through a separate trusted channel, that you are changing devices and that they should expect a safety number change.
- During setup: if the app offers an account transfer or restore flow, use it. A fresh registration without transfer generates new identity keys; a transfer carries them over. This distinction comes from a third-party guide, not a retrieved official page, so confirm the current flow in your app before relying on it.
- After switching: re-verify with the same contacts, in person if possible.
- Always: keep a secondary safe channel established with anyone you communicate with sensitively, so you have somewhere to check in if something unexpected happens.
What to do today
Pick the one conversation where a substituted key would actually hurt: the source, the lawyer, the accountant, the co-founder. Open it, view the safety number, and compare it in person or through a channel you already trust. Mark it verified. Write the date down. That is the whole task, and it takes less time than the meeting you are about to join.
Then, before your next device switch, send the heads-up message. The worst time to discover that your re-verification process is unclear is after your contacts are already staring at a changed number and wondering what it means.
Frequently asked questions
Does a changed safety number mean I have been hacked?
No. Signal’s own documentation says keys change when people get a new phone or reinstall the app (Signal, 2016). A change is a prompt to re-verify, not proof of compromise. Frequent or unexplained changes are a reason to slow down and check through another channel.
Can I verify by sending my safety number over Signal itself?
No. Both parties see the same number, so sending it over the same channel proves nothing. Use a channel you already trust for that person, and let the person doing the verifying receive the number rather than send it first.
Does a matching safety number prove who the person is?
No. It proves that the Signal conversation is tied to the identity you verified through the other channel. The trust in the human comes from that other channel, not from the number.
What if I cannot meet in person?
Use an already-established channel: an email thread you have used before, a phone call to a number you already had, a video call where you can see the person. The strength of the verification is the strength of that channel.
Where can I read the primary documentation?
Signal’s X3DH specification is at signal.org/docs/specifications/x3dh/. Signal’s 2016 post on safety number updates is at signal.org/blog/safety-number-updates/. Both are worth reading alongside this article; the first explains what the comparison authenticates, and the second explains why the interface looks the way it does.