Why Standardizing Threat Actor Names Alone Is Not Enough

Microsoft, CrowdStrike, Palo Alto Networks, and Mandiant recently announced a new initiative to create an aggregate and standardized glossary of threat actors. While threat actor nicknames like Fancy Bear or Caramel Tsunami inject a sense of drama into the cyber space, transforming oftentimes tedious work into a narrative of secret superheroes versus villains, it doesn’t do much for the security teams working to understand the threat environment and how it impacts their defenses.

Up until now, different vendors used their own naming conventions to classify threat actor groups. For example:

CrowdStrike uses an adjective-animal naming convention.e.g., Fancy Bear, Putter Panda
Mandiant employs a three-letter acronym prefix attributed to the threat actor type followed by a numerical system.e.g., APT29, FIN6
Palo Alto Networks (Unit 42) uses thematic names.e.g., Cloaked Ursa, SilverTerrier
Microsoft leads with a weather/geology-based approach.e.g., Amethyst Rain, Cotton Sandstorm

These naming styles lack consistency, obscure attribution, and fail to provide immediate context. For example, a Russian-linked espionage group, when analyzed by these vendors, is often broken down in similar but not identical ways. Some focus on tactics, tehchniques, and procedures (TTPs), others highlight associated tools (rather than how they’re used) or malware families, and some rely heavily on proprietary telemetry from their vendor ecosystem. This leads to the naming of this espionage group as APT29 by Mandiant, Cozy Bear by CrowdStrike, Midnight Blizzard by Microsoft, and Cloaked Ursa by Unit 42. This nuance becomes more significant when factoring in the evolution of a threat actor over time (from both a technological and tactical standpoint) or when multiple threat actors reorganize (i.e., either merge or fragment).

This complexity makes it difficult for security and risk leaders to validate whether their controls and mechanisms can detect or defend against a known adversary when names differ across vendors. It further undermines situational awareness, as a detection from one vendor may not be linked to another’s report on the same actor. This causes friction for security professionals, forcing them to build internal ontology/taxonomy maps or rely on vendor-supplied translations. This creates operational drag and inefficiencies across both customers and vendors, which this joint initiative aims to reduce.

Your Work Begins Where Standardization Ends

As organizations begin to evaluate the impact of this new threat-actor naming normalization initiative, it’s important to ground expectations in operational reality. While the intent has value, its success depends on how well it can be integrated. Security leaders need to know that:

Naming normalization enhances threat intel workflows. Naming normalization becomes useful when it streamlines threat hunting, correlation, and threat intelligence enrichment. Most security teams rarely act on the name of a threat actor, as concrete indicators, TTPs, and contextual information on the impact on the organization’s technology stack, geography, or industry matter a lot more.
Naming methodologies must be abstracted. Expect vendors to continue using their own analytic frameworks for adversaries — driven by their telemetry, proprietary tooling, and in-house expertise. The naming standards must allow for flexibility; without this, it could cause them to act as another source of friction rather than clarity. The taxonomy should support exceptions without breaking down.
Integrate open mapping and extensibility to ensure consistency in standardization efforts. If security and risk leaders build internal reporting and tooling around the new standardized naming convention, it must include a way to translate the aliases of actors for nonparticipating vendors. If not accounted for, security leaders would end up with a dual system, and the same fragmentation issue would persist. Interoperability and continuous mapping are nonnegotiable for this initiative to work operationally. This is something we will learn over time as this standardization approach matures.

This is a positive step for the industry, but there’s nothing game-changing here. Most organizations today rarely use naming conventions to drive actions by themselves. Consistent naming may help threat intel teams communicate better and reduce confusion over time, but it won’t improve your security posture on its own.

Standardization Is Incomplete Without Open Mapping And Shared Infrastructure

If vendors are serious about this initiative, the next step is clear: Create a standardized naming schema and open-source API that maps threat actor aliases to a single meaningful identifier that is collaboratively maintained and accessible to all. In the long term, it would make more sense for this effort to be led by a neutral and trusted entity rather than a vendor (or group of vendors) that might have alternate incentives outside of cyber, such as branding/marketing. This would truly enable the broader community to operationalize this effort, contribute meaningfully, and drive real intelligence maturity across the board.