Can you use Signal without a phone number? (2026)

Can you use Signal without a phone number? Not to create a new account as of 20 August 2026. Signal’s registration support says the service uses an existing number that can receive an SMS or phone call. After registration, Signal usernames can let a new contact start a conversation without seeing or knowing that number, and discovery controls can narrow who finds you by it. That is a meaningful privacy improvement, but it does not make registration numberless. I am building UmbrellaX around a different identity direction: a telecom identifier should not be the account root. UmbrellaX is pre-launch, so that is a design commitment rather than a claim about a released workflow.

The distinction is easy to miss because both questions sound like “can I use Signal without my phone number?” One asks what another person sees. The other asks what the account system requires before anyone can message.

Signal has improved the first answer substantially. I think it deserves credit for that. But I would not let a better contact surface blur the second answer, especially when a reader is deciding whether a carrier-issued number belongs inside their threat model.

The answer first

Signal currently requires a phone number to register a new account. Its registration support page says the number must be able to receive an SMS or phone call. Once registered, a Signal username can let someone initiate contact without being given your number, and the app’s privacy controls can limit who discovers you by that number. Those features improve contact privacy. They do not replace the number used at registration. If your requirement is simply “do not hand my number to a new contact,” Signal can meet that need well. If your requirement is “do not make a phone number part of my account foundation,” the answer is still no, and you need a different identity model.

That is not a criticism disguised as a technicality. It is the practical decision boundary. I would choose a privacy control based on what it actually changes, not on the most reassuring version of its name.

Why the answer has two parts

The word “use” hides two different moments.

At registration, Signal asks for a number and sends a verification message or call to it. Signal’s legal policy also describes a registered phone number as account information. The phone network is therefore part of the onboarding boundary, even though it is not the only thing that protects the account afterward.

At contact time, the situation is better. A person who needs to share a way to reach them without distributing a phone number can use a username, a QR code, or a link. Signal describes usernames as a way to initiate contact without sharing the number. That matters for a journalist publishing a tip channel, a volunteer joining a new group, or anyone who does not want a fresh acquaintance to gain a durable telecom identifier.

My rule is to name the boundary precisely. Contact privacy means the recipient does not need the number. Account independence means the service did not need the number to establish the account. Those are both useful goals, but they are not interchangeable.

What a Signal username changes

Signal’s username explainer makes the useful part clear: a username is not the profile name people see in chat, it is not a public directory listing, and it can be shared to begin a conversation without disclosing the registration number to that person.

I would use that feature when my immediate problem is sharing a safer contact path. A username is easier to give to a source, a new client, or a community member than a number that may also connect to a carrier account, old address books, banking alerts, or years of unrelated signups.

Signal also offers controls for who can find an account by its number. That matters because hiding a number on a profile does not automatically stop someone who already has the number from using it as a lookup key. The stronger Signal setup is therefore a combination of visibility settings, discovery settings, and a deliberately shared contact path.

Those are real protections. I do not want readers to skip them because the larger account-root question remains unresolved. Privacy improves in layers, and a good layer is still worth using.

For the wider design question, read my messaging app usernames guide. It explains why a handle needs rotation, narrow discovery, and a boundary from a public identity. This page stays with the narrower Signal decision: a username changes how new contact begins, not how the account begins.

A registration number is still an account boundary

Phone numbers are convenient because people already understand them. They also have properties I do not want to quietly inherit as an account foundation: a carrier controls issuance and porting, a number may be reassigned, and a person can have a complicated relationship with the identity records attached to it.

NIST’s digital identity guidance treats PSTN-based out-of-band authentication as a restricted authenticator. That does not mean every messenger that verifies a number is unsafe. It means the phone network has limits that deserve a sober design response.

My account-root test is not whether a product has end-to-end encryption. Signal’s encryption and its contact-privacy work are valuable. I ask a different question: if I could not safely use a carrier number, would I have a legitimate way to create and keep this account?

For Signal today, the answer is no for initial registration. For the full architectural case, I defer to messenger without a phone number. That page covers telecom identity, number recycling, contact discovery, and metadata in depth. Repeating that whole guide here would turn a direct product answer into a vague privacy essay.

I would not turn registration into a workaround hunt

Search results for this question often turn into a list of ways to acquire a number that looks less personal. I think that is the wrong answer to publish.

It can leave a person dependent on an account or service they do not understand, and it may collide with a messenger’s anti-abuse rules or create a recovery problem later. More importantly, it teaches the reader to treat a design constraint as a puzzle to evade instead of a boundary to evaluate honestly.

My rule is simpler: if your threat model does not allow a phone-derived account identifier, choose a messenger whose normal account model respects that requirement. Do not build a sensitive communication plan on a fragile exception.

The same principle matters after a number changes hands. A SIM swap attack and secure messaging accounts needs a specific incident response, and a phone number privacy guide separates visibility, discovery, matching, and recovery. Neither topic needs to be duplicated here. The narrow conclusion is enough: carrier identity is not only a profile field when it sits in registration.

A Signal PIN has a different job

A Signal PIN is easy to misunderstand if you arrive through a registration search.

Signal says its PIN can help recover profile information, settings, contacts, and a block list when a person switches or loses devices. Signal also states that the PIN is not the SMS registration code and is not a chat backup. That separation is a sensible safety boundary: recovering an account context does not automatically mean reopening every old conversation.

I would keep that distinction visible in any private messenger. One secret or recovery event should not silently become a master key for identity, devices, and message history. That does not eliminate the registration requirement, but it prevents us from describing every recovery tool as if it solves the same problem.

Our encrypted chat backups guide goes deeper on recovery and history. The relevant point here is small but important: a Signal PIN does not turn a phone-number registration process into a numberless one.

What I would choose based on the risk

If I already use Signal and my main concern is preventing a new contact from learning my number, I would use the username and number-discovery controls, then check the current settings after each major app update. I would not share a registration code with anyone. Signal’s support guidance is explicit on that point.

If I need to protect against a carrier incident, I would treat the number as one part of a broader account-security review. I would look at linked devices, registration lock, recovery material, and whether a suspicious event needs support attention. The incident guide above is the right place for that sequence.

If I cannot accept a phone number at the first account step, I would not ask Signal’s username to solve a problem it was not built to solve. I would choose a messenger with a no-phone-number account model, and I would examine its recovery and contact-discovery tradeoffs with the same scrutiny. Removing one identifier does not make the rest of the threat model disappear.

The UmbrellaX direction I am building toward

UmbrellaX is pre-launch. I cannot claim that a finished onboarding or recovery flow has been tested by users, audited, or deployed at scale.

What I can state is the design choice I am building toward: a person should not need a phone number as the root of a private messenger account. I want contact to start through deliberate paths, such as a scoped handle, invite, or other consent-based exchange, rather than making a telecom namespace the default map of who exists in the product.

I accept the tradeoff. Automatic address-book growth is easier when a number is already the universal key. I would rather accept more intention at first contact than let convenience decide who the operator can connect by default. Encryption by default remains necessary, but identity setup and retained operational context are part of the privacy decision too.

My UmbrellaX versus Signal comparison owns the wider product comparison. Here, the practical conclusion is narrower: Signal usernames help a person share contact without revealing a number, while UmbrellaX is being designed so the phone number is not the account foundation in the first place.

The questions I would ask before signing up

Before I trust any messenger’s claim that it works “without a phone number,” I would ask:

1. Is a number required to create the account, even if other users never see it?
2. Can people who already know the number discover the account?
3. Can I start a conversation through a deliberate contact path instead of an address-book match?
4. What happens if the number is lost, ported, or reassigned?
5. What does account recovery restore, and what does it deliberately leave alone?
6. What does the operator learn from registration, lookups, invites, and device changes?

The questions are not a request for perfect anonymity. They are a way to avoid giving one setting credit for a different privacy job.

Bottom line

Can you use Signal without a phone number? You can use its usernames and privacy controls to communicate with new contacts without giving them your number, but you currently need a number to create the account. That is a stronger answer than the old mainstream messenger pattern, and it is worth configuring correctly.

If your requirement is no number sharing, Signal can offer a practical path. If your requirement is no phone-derived account root, choose that architecture from the start. That is the standard I am building toward with UmbrellaX: a deliberate identity model, encryption by default, secure groups, and less operator knowledge around the relationship before a message is sent.