Communication baseline

Expanded Definition

A communication baseline is not a content filter or a simple sender allowlist. It is a learned pattern of normal organisational communication across people, vendors, and systems, capturing who typically talks to whom, at what cadence, in what tone, and with what request structure. In NHI security, this matters because a message can be technically valid, use a legitimate mailbox or chat account, and still be socially abnormal. The baseline sits alongside identity and access controls so analysts can spot deviations that suggest impersonation, vendor compromise, or workflow abuse.

Industry usage is still evolving, and definitions vary across vendors. Some products focus narrowly on email metadata, while others extend the baseline to collaboration platforms, ticketing systems, and API-driven notifications. A useful reference point is the broader detection and response model in the NIST Cybersecurity Framework 2.0, which emphasises monitoring, anomaly handling, and response coordination across the enterprise. The most common misapplication is treating a communication baseline as a one-time allowlist, which occurs when organisations fail to update it after vendor changes, new automations, or shifts in executive communication patterns.

Examples and Use Cases

Implementing a communication baseline rigorously often introduces alert tuning overhead, requiring organisations to weigh stronger social-engineering detection against the operational cost of maintaining current patterns.

• A finance team normally receives payment requests from a fixed vendor domain, but a message with the correct branding arrives from a newly registered lookalike address and triggers review.
• An executive assistant regularly sees approvals routed through a known workflow; a same-day request that bypasses the usual channel is flagged even though the sender account is valid.
• A service account usually sends routine notifications at predictable intervals, but an out-of-cycle message with unusual recipients suggests compromised automation or token misuse.
• Security teams compare message timing and request structure against lessons from the Ultimate Guide to NHIs to distinguish routine machine-to-human traffic from deceptive outliers.
• Analysts use baseline deviations together with guidance from NIST Cybersecurity Framework 2.0 to prioritise suspicious requests that merit escalation or workflow verification.

Why It Matters in NHI Security

Communication baselines matter because many NHI incidents begin with a message that looks routine but arrives at the wrong moment, through the wrong path, or with the wrong authority context. When an attacker compromises a service account, a vendor mailbox, or an agentic workflow, the message content may be polished enough to bypass simple detection. A baseline helps expose those subtle breaks in pattern that are easy to miss when teams focus only on payload content or sender authentication.

This is especially important in environments where NHIs outnumber human identities by 25x to 50x, because communication volume and automation create more opportunities for abuse. It also supports governance for machine-originated requests that feed approvals, secrets access, and privileged actions. The same operational discipline described in the Ultimate Guide to NHIs becomes essential when identity compromise is already suspected, because baseline drift often reveals the first sign of misuse. Organisations typically encounter the relevance of a communication baseline only after a fraudulent request, vendor impersonation, or workflow takeover has already triggered loss, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is agent communication poisoning?
• Why does leaving Linux outside the passwordless baseline increase identity risk?
• Why do communication tools create sovereignty risk for IAM teams?
• Who is accountable when a communication platform does not meet sovereignty requirements?