Secure Communications & Trusted Decisions for Executives

Reading time ~12 minutes · No technical prerequisites · Day 2, Module 2.5

The attacks that cost executives the most are rarely dramatic technical break-ins. They are convincing requests — to move money, share data, or approve something — pushed down a channel that looks trusted. Securing communications, for a leader, is therefore less about choosing an encrypted app and more about verifying who is really on the other end and protecting the act of deciding.

Four properties, one that leaders neglect

Secure communication rests on four properties: confidentiality (only the intended parties can read it), integrity (it was not altered in transit), authenticity (it truly comes from who it claims), and availability (you can use it when you need it). Most tools deliver confidentiality well. The attacks that actually hurt executives exploit authenticity — the hardest property to guarantee, because it concerns the human on the far end, not the mathematics of the channel.

Encryption and its two blind spots

End-to-end encryption means only the endpoints can read a message; the provider and the network cannot. It is essential, and it has two blind spots a leader must remember. First, it protects the message in transit but not a compromised endpoint that already holds the plaintext — the mobile threat of Lesson 08. Second, it hides what you said but not the metadata: who you spoke to, when, how often, and from where.

Verify people, not channels

A secure app confirms that the channel is encrypted; it does not confirm who holds the device at the other end. That is why serious practice includes out-of-band verification — confirming identity, or a cryptographic safety number, through a separate route the adversary does not control. A trusted-looking channel is not the same as a trusted person, and authenticity is always about the person.

The executive verification rule

Business-email-compromise and fraudulent-instruction attacks succeed by pushing a plausible, urgent request down a channel you already trust. The defence is a single rule applied every time: when an urgent request to move money or share sensitive data arrives, do not act on the channel it arrived on. Call back on an independently-known number, confirm with a pre-agreed code word, and only then act. Urgency is not a reason to hurry; it is the attacker's most reliable tool, engineered precisely to stop you verifying.

Never verify a request using the channel that made it. Confirm the person through something the adversary does not control.

Deepfakes, PACE, and the culture of the pause

Convincing voice and video clones of trusted people are now cheap, so "it sounded exactly like them" is no longer evidence of anything. Reassuringly, the verification rule was never based on recognising a voice: a clone cannot pass an independent callback to a known-good number, and cannot produce a pre-agreed secret it was never told. To make verification practical under stress, plan your channels in advance using PACE — Primary, Alternate, Contingency, Emergency — which gives both resilience and a ready independent path for out-of-band confirmation. Finally, none of this works without culture. Staff defraud themselves because they fear questioning authority; a leader must give explicit permission to slow down and verify a request, even one that appears to come from the boss. A short verification delay almost never costs a legitimate deal, and making "verify first" something people are thanked for is what actually closes the fraud.