Signal Rolls Out Automatic Key Verification Backed by Cloudflare and Trail of Bits Audits on August 12, 2026

What changed in Signal on August 12, 2026

Signal introduced a feature called automatic key verification to confirm nobody has secretly interfered with encrypted chats, framing the addition as a streamlined alternative to manual safety number checks for users who want assurance that no unexpected party sits between them and the other side of an end-to-end encrypted session. The mechanism is delivered through a key-transparency system: every phone-number or username change, account re-creation, or fresh registration feeds a new entry into a continuously growing public-key ledger that Signal maintains and that two outside organizations independently audit.

To use it, a Signal user opens a contact's profile, taps View Safety Number, and selects Verify automatically; on a clean match the app displays a green checkmark alongside the words "Encryption verified," giving a non-expert user an at-a-glance confirmation that the contact's published public key is the one Signal's audited ledger says should be present. Help Net Security and BleepingComputer both reported the launch on August 12, 2026, while SC Media published a brief the same day describing the feature as a defense against man-in-the-middle attacks.

The category context is encoding and cryptography: Signal is changing how public-key material is bound to identifiers, not the underlying Signal protocol itself, and that distinction matters because the cryptographic primitive being augmented is the association between phone number, username, and key, rather than the cipher used to encrypt message contents.

How the new verifier actually works, and what it cannot do

Signal engineer Katherine Yen wrote that automatic key verification "works through a system of verifications performed by you, your Signal connections, and third-party auditors that together provide the same assurance as manually verifying safety numbers," and that the system protects against a malicious party compromising Signal's directory and associating a different key with a connection's phone number or username without the key owner's knowledge. Two outside organizations, Cloudflare and Trail of Bits, independently audit the key-transparency server, and the information available to those auditors is cryptographically protected so they do not receive users' phone numbers or usernames in plaintext, which means the audit role is structural rather than a window into message content.

Signal explicitly frames the threat model as an attacker who controls the key directory or a privileged insider who abuses access, a scenario the company describes as unlikely because it would require breaking into major cloud infrastructure or a deliberate insider going after a specific account. The same Signal guidance, however, is candid about scope: key transparency helps establish that Signal users are seeing a consistent record of which encryption keys belong to which accounts, but it does not establish the real-world identity of the person controlling an account, and it does not protect against someone who has completely taken over a legitimate account.

Readers handling cryptographic trust decisions should therefore treat the green checkmark as a directory-consistency proof, not as identity verification or session-level attestation.

Practical reader impact, opt-out path, and limits

The user-visible flow is short: open a contact's profile, tap View Safety Number, choose Verify automatically, and read the green checkmark and "Encryption verified" label, while anyone who prefers not to extend trust to Signal and the independent auditors can disable automatic key verification under Signal's Privacy > Advanced settings and continue relying on manual Safety Number verification. There is an important availability caveat that production teams and security leads should communicate to staff: automatic verification currently depends on Signal having the contact's phone number and may therefore be unavailable when a conversation was started using only a username, in which case users can still manually verify Safety Numbers.

The feature's threat model is also narrower than casual readers may assume, because key transparency helps establish that users are seeing a consistent record of which encryption keys belong to which accounts, but does not establish the real-world identity of the person controlling an account or protect against someone who has completely taken over a legitimate account. Practically, this means organizations should brief high-risk users, such as journalists, activists, and executives, that the green checkmark confirms the directory path, not the person on the other end, and that identity or full-account-takeover scenarios remain out of scope.

Practicing what the new flow teaches, an analyst can sanity-check local key-handling logic with the RSA Key Generator or refresh symmetric-cipher routines against AES Encryption Online, which keeps the audit habits on the same footing as the trust model Signal is now exporting.

Backdrop and confirmed prior incidents

In May, Signal added new protections for users after Russian state-sponsored hackers targeted high-profile accounts with fake "Signal Support" alerts, abusing Signal's Linked Device feature to reach a target's account, chats, and contact lists. S. Department of State later announced bounties of up to $10 million for members of the UNC5792 and UNC4221 hacker groups linked to widespread phishing campaigns targeting Signal users, and the FBI, German authorities, and the Dutch government reported on related activity, as summarized in BleepingComputer's August 12, 2026 coverage.

Signal's own framing of the new feature as protection against "a malicious party compromised Signal and associated a different key with your connection's phone number" sits in the same threat family as those phishing-driven takeovers: in both cases the attacker tries to insert themselves into a target's trust path, although the May incidents targeted account recovery and Linked Device workflows, while automatic key verification targets directory-level key substitution. " Readers should note that the May 2026 phishing wave and the August 12, 2026 launch are reported by publishers as separate items in Signal's hardening trajectory rather than as a single combined release, which keeps the causal attribution clean.

Uncertainty and what to watch next

The most important uncertainty is what automatic key verification does not cover: it is a directory-consistency mechanism, so it does not establish the real-world identity of the person controlling an account or protect against someone who has completely taken over a legitimate account, and Signal says so plainly in its own description. Automatic verification also currently depends on Signal having the contact's phone number and may therefore be unavailable when a conversation was started using only a username, leaving username-only conversations on the older manual Safety Number path until Signal changes that requirement.

The Cloudflare and Trail of Bits audit relationship is described as independent and cryptographic, with auditors receiving protected rather than plaintext identifiers, but the published material does not yet disclose an audit-criterion schedule, a transparency-log public endpoint, or a formal deprecation timeline for the manual fallback, and those gaps are exactly what cryptographic operators will want filled before they treat the green checkmark as a regulated control. Watch for Signal to publish a key-transparency log reference implementation or public verifier, to extend the feature to username-only conversations, to ship a published audit cadence from Cloudflare and Trail of Bits, and to clarify whether automatic verification will become the default for new chats, because each of those steps will materially change how the new checkmark should be weighted in policy.

Until those disclosures appear, the honest read is that Signal has narrowed one specific directory-substitution risk while leaving identity, full-account-takeover, and username-only flows untouched.