Why Signal's New Safety Features Are Fighting the Last Campaign
Every channel people trust eventually becomes a channel attackers exploit.
Signal's response to a Russian state-sponsored phishing campaign frames this as an information problem. Warnings asking users to question that trust, fighting human communication instincts.
On May 11, 2026, Signal announced a set of in-app protections against phishing and impersonation, including "name not verified" labels on profile names, a second confirmation prompt when users accept message requests, and expanded safety tips. The features are a response to a campaign attributed to Russian Federal Security Service officers who impersonated Signal Support to trick users into sharing verification codes and linking attacker-controlled devices. The FBI, CISA, and Dutch and German security authorities all issued advisories.
Signal's response assumes these attacks can be stopped with more information — i.e. if users knew that profile names were unverified, and that Signal would never ask for PINs, they would behave accordingly. This deficit-based account seems reasonable. When knowledge or situational awareness is missing, a well-timed nudge can improve it. It's a common problem that enterprise software has tried to solve for decades. Alerts are simply swept away with other tasks and priorities that compete for attention.
The deficit model ignores the channel itself. Apps are designed to facilitate communication; and when they succeed, the properties of the channel become invisible. Trust accumulates through thousands of frictionless interactions, extending from individual users to the channel as a whole. This is ambient trust. Alerts, prompts, and confirmation dialogs all interrupt that flow. Human-centered security design might see this as a feature, but this is the attack surface.
The Durability of Ambient Trust
Trust is a product of technology domestication. People don't think of a phone as a small, networked computer. It’s a reliable companion that provides a one-stop source of entertainment, scheduling, and communication. Apps from a trusted provider downloaded from a trusted store inherit that confidence. Meta's association with the Cambridge Analytica scandal, and their recent removal of end-to-end encryption from Instagram DMs demonstrates that trust endures. Even when users cite privacy concerns, they continue disclosing information sold to partners and visible as OSINT to anyone watching. The company is implicated, but the channel endures.
The negative public response also highlights something often ignored: there is an implicit social contract between users and companies. It doesn’t matter that they are a corporate entity, the expectation of trust remains.
In the context of enterprise, the employer's adoption adds perceived validation. Employees must assume their employers have a rational self-interest in preserving organizational assets. The issue is that most companies do not analyze content in language-based channels. When they do, they focus on email attachments, spoofed IPs, and caller numbers — not conversational manipulation. Apps like Signal provide workarounds for employees even when official channels are secured. High-profile missteps by U.S. government officials show how consequential and how casually trusted these channels become.
Why Conversational Momentum Beats Behavioral Nudges
User attention is finite, and nudges must compete for it against the twin-forces of conversational momentum and ambient trust.
Momentum is a property of the channel. Attackers can do their own nudging, but the speed of communication is natural. Words can be processed in fractions of a second, and senntences can be constructed and produced within little conscious thought. Real-time messaging keep deliberation at a minimum: typos and poorly chosen words are everyday artifacts of this process. The expectation of a reply is immediate. If the message is formal, the clock is ticking. If it is informal, ignoring it carries a social cost. In either case, not responding can require more cognitive effort than responding.
A nudge that interrupts this flow, whether a label, a confirmation prompt, or a safety tip, means the user must override both the social pressure to keep the conversation moving and the trust they have in the channel. This is why nudges can only be part of the solution. Alerts are simply swept away with other tasks and priorities that compete for attention.
This is supported by research. Nudge-based security interventions produce ~11% improvement in targeted behaviors. A large-scale field study, Alice in Warningland, found click-through rates of 9-23% for phishing warnings, and 70% for SSL warnings.
Nudges do not just compete for attention, they redirect it. A platform's security update focuses the user on the specific threat it names, drawing attention away from everything else. If no additional training or warnings are provided, an employee will focus on those patterns. The next campaign will go unnoticed. Google's scam detection in Messages has the same logic. These systems are trained on documented fraud categories, and can find these patterns. If an attacker avoids them, an attack will go undetected.
Outside of security studies, we know that limited experience and expertise boost confidence more than performance. This creates security overconfidence both in employees and in organizational leaders who believe training and nudges are sufficient. Like a magic trick, the user focuses on the right hand while missing the attacker steals with the left.
Formally or informally, platforms use design frameworks that draw from MINDSPACE (Messenger, Incentives, Norms, Defaults, Salience, Priming, Affect, Commitment, and Ego). Each nudge is designed to improve awareness, creating cognitive patches to increase cyber hygiene behaviors and decrease susceptibility to social engineering.
Table 1. Behavioral nudges, cognitive patches, and remaining issues
Designers might assume that such nudges combined with training will be effective. They are certainly better than nothing. But they create a sense of addressing the problem, while the efficacy of social engineering persists. Even when used together, they define a performance ceiling.
The evolution of the Signal impersonation and phishing campaign supports this. On June 26, 2026, the FBI and CISA updated their March advisory, attributing the activity to multiple Russian Intelligence Services clusters (UNC5792 and UNC4221). The objective had changed. Earlier waves targeted verification codes and PINs. Signal has this covered. The updated wave a focuses on users’ Signal Backup Recovery Key, requested through messages that appear like a mandatory two-factor rollout or an urgent data-recovery fix. When successful, users have handed over the account's backup, message and group history, and persistent access.
From Individual Alerts to Organizational Awareness
Problems that affect individual users, accumulate at the organizational level. A nudge can sharpen one person's detection in one moment. It cannot tell them what the attacker's next move will be, or tell the organization that an attack is underway. Every organization that uses Signal, Teams, WhatsApp, or Slack for work or uses a similar system must acknowledge the gap in defense.
To address this, organizations must develop their distributed situational awareness: people, systems, and information channels together monitoring the full attack surface. This approach frames awareness as a property of the sociotechnical system, in which one agent's awareness compensates for the limits of another's. Most employees are neither reliably aware of cybersecurity risks nor consistently compliant with security policy, even with training. This is an organizational problem, not an employee problem.
Table 2. Situational Awareness Levels: Each corresponds to the kind of knowledge that a person or situational network has
We cannot expect employees to be aware of every policy, every procedure, and every project in any given moment. The expansive nature of the human and technical attack surface is too great. Attackers will discover the gaps if you do not; whether by themselves, in a distributed supply chain, or using their own stack.
At an organizational level, situational awareness is compromised by missing threat taxonomies, signal telemetries, incident and response transparency, and social engineering tactics. But organizational leaders should ask themselves specific questions about how much situational awareness they have across the people, systems, and information ecology.
Table 3. Situational Awareness Self-Assessment: Questions organizational leaders can ask across people, systems, and information ecology at each level
Within organizations, most security programs focus on the first level. SIEMs often focus on simple signals for detection and response without sufficient resources to consider the relationship between signals and system states. They assign a label or provide an alert that is triaged: either attend to or lost in the stream of events. Approaches like UEBA touch the second level of awareness but are commonly limited by chronic issues with creating user baselines and understanding context.
The third level of awareness is rarely broached outside of ‘thought leadership’ pieces. For organizations currently unaffected by an attack, the FBI/CISA model provides what information is available in a third level. For those that have been attacked, there tend to be gaps in comprehension of the attack, predictions of how attacks evolve, and the translational processes between layers that remain unaddressed. Cybersecurity is largely reactive rather than proactive.
Improving situational awareness requires improved efforts for internal organizational communication and external coordination. This requires more than a series of nudges. Cybersecurity leaders need to ensure that the right people or systems are receiving the information they need to respond. They must identify how information is collected, analyzed, translated, and actioned in each communication channels for capabilities and capacities for detecting threats in real-time.
What is feature engineering
In practice, feature engineering is both science and a bit of witchcraft. It often involves both iteration and experimentation to uncover hidden patterns and relationships within the data. For instance, a data scientist might transform raw sales data into features such as average purchase value, purchase frequency, or customer lifetime value, which can significantly boost the performance of a churn prediction model. By thoughtfully engineering features, practitioners can provide machine learning models with the most informative inputs, ultimately leading to better accuracy and more robust predictions.
What’s more?
- Incorporate more and more data sources
- Feature engineering platform
What is data engineering
As we mentioned above, feature engineering is certainly a subset of data engineering. It involves the ingestion of data from a source, applying a series of transformations, and making the final result available to be queried by a model for training purposes. You can construct feature engineering pipelines to resemble data engineering pipelines, having schedules, specific source and sink destinations, and availability for querying. However, this configuration would only really apply once you have surpassed the experimentation stage and determined a need for a consistent flow of new feature data.
What is feature engineering
1. Functions
Functionally, there is nothing to differentiate data vs features - data points (link). Where feature engineering and data engineering really differ is in the objectives and motivations for constructing the pipelines. In general, data engineering serves a broader, more unified purpose than feature engineering. Data engineering platforms are constructed to be flexible and universal, ingesting various types and sources of data into a unified storage location where any number of transformations and use cases can be applied. The intent of a well constructed fact table or gold layer in a data lake is to provide a single source of truth that answers many different questions, produces many reports, and can be consumed by many downstream customers.
2. Practise
And in practice, an organization’s data engineering team will be responsible for the curation and maintenance of all data pipelines, not just those that relate to machine learning. These pipelines may power BI dashboards used by C-Suite, auditing reports that feed payroll, or event logs that show a user’s history of actions within the application.
Feature engineering, on the other hand, serves a specific purpose, finding the tailored inputs and columns that will generate the best predictive results for a machine learning model. Data scientists and machine learning engineers are not tasked with developing a universal data model that will ingest all data points throughout an organization, they just need to select, curate, and clean the data needed to power their models.
3. Machine learning
Now, as machine learning teams grow and begin to incorporate more and more data sources into their models, their feature engineering platform may start to resemble a larger data engineering platform in the tools and methodologies they employ. But, the intent is not to establish flexible data models that can be used throughout the organization - it is simply to power their machine learning models.
.png)
