Field notes from RSA Conference 2024: the secure-transfer conversations vendors aren't having

RSA Conference 2024 was, by the numbers, another record year — somewhere north of 40,000 attendees, more than 600 exhibitors, and the usual blend of vendor theater and genuinely useful hallway conversations. We were in the South Hall with a booth, but the observations that are actually worth writing up didn’t come from the floor. They came from the CISO-track sessions, the side meetings, and the conversations that happened around the edges of the official program.

Here are the four things that stood out for us, in roughly the order we stopped dismissing them as niche concerns.

The CISO-track theme nobody put on the program

Nobody titled a session “third-party data transfer is your biggest unmanaged attack surface.” But if you sat through the CISO roundtables and read the subtext, that’s what kept surfacing. CISOs at regulated organizations — financial services, healthcare, defense contractors — are increasingly focused on the moments when data leaves their control: the file sent to outside counsel, the dataset shared with a due-diligence firm, the configuration export sent to a managed service provider.

What they’re finding, almost universally, is that they have excellent controls on data at rest and reasonable controls on data in transit within their perimeters, but the handoff moment — the actual transfer to an external party — is a governance gap. The data leaves the SIEM coverage, leaves the DLP monitoring, and lands somewhere they can’t audit.

The vendors filling the floor were talking about identity, detection and response, and AI security. Nobody was talking about the governed handoff. We talked to eleven CISOs over the course of the week; eight of them raised this gap without prompting.

The boundary-verification gap

The second theme is closely related: how does a regulated entity verify that the receiving party actually controls the destination? This sounds like a solved problem — you send to an email address, they click a link. But the threat model is more sophisticated.

ATT&CK technique T1078 (Valid Accounts) and T1550.001 (Application Access Token) describe the reality: in a compromised environment, the receiving organization’s account may be valid but attacker-controlled. If your transfer mechanism authenticates to an email address, and that email address is under adversary control, you’ve delivered the file to the right address and the wrong party.

Several sessions touched on the boundary-verification problem without naming it that way. The consensus in the rooms we were in was that email-linked delivery and consumer file-sharing links both fail this model — they authenticate the channel, not the identity. Strong recipient authentication — MFA-gated download, authenticated delivery receipts that prove a specific enrolled identity retrieved the file — came up repeatedly as a capability gap in the tooling most organizations actually use.

This isn’t a new concept. The gap is that adoption of stronger delivery verification has lagged behind the threat model.

Post-quantum on file transfer

NIST finalized its first post-quantum cryptography standards in 2024: CRYSTALS-Kyber (now ML-KEM under FIPS 203) and CRYSTALS-Dilithium (now ML-DSA under FIPS 204) are the primary key encapsulation and signature algorithms respectively. The cryptography track at RSA had several sessions on migration timelines, and the framing has shifted noticeably.

A year ago, PQC conversations in practitioner settings were about “harvest now, decrypt later” — the concern that adversaries are collecting encrypted data today to decrypt when quantum capability matures. That concern is still valid, but a new urgency has entered the conversation: compliance timelines. NIST’s guidance to federal agencies on PQC migration is creating procurement pressure that will flow to the vendors those agencies use.

For file transfer specifically, the practical question is: which vendors have a documented PQC migration roadmap, and how does it affect stored data versus in-transit data? Data encrypted today with RSA-2048 key exchange, if harvested, is a future liability. The migration path for file-transfer platforms requires both in-transit encryption algorithm migration (replacing RSA/ECDH key exchange with ML-KEM) and a re-encryption path for archived data.

We were asked about our PQC roadmap roughly a dozen times during the conference. We have one, and we’re publishing it on our security page. The short version: we’re targeting ML-KEM support in TLS 1.3 hybrid mode by H1 2025 and completing the stored-data re-encryption path before the end of 2025.

The surprise of the week

We expected to talk about identity. We expected to talk about compliance. We didn’t expect to spend as much time as we did talking about internal file-sharing — specifically, the problem of regulated data moving between departments inside regulated organizations, where the tooling is often even less controlled than external transfer.

The pattern that came up repeatedly: an organization has a rigorous process for sending PHI or MNPI to outside parties and almost no process for moving the same data between internal business units with different classification requirements. The finance team sending a customer list to the marketing team. The legal team sending discovery materials to an internal investigator. The compliance team sending exam response documents to the executive team.

Internal transfers sit in a blind spot. They’re not external enough to trigger the third-party review process, but they cross trust boundaries that have real regulatory significance. Several attendees described discovering, during audit prep, that their internal file-sharing tooling had no audit log, no expiry on shared links, and no encryption in transit.

The conversation kept coming back to the same point: a file-transfer policy that only covers external transfers is half a policy.

We’re incorporating that feedback into our product roadmap — specifically around internal team transfer workflows with the same audit and encryption posture as external transfers. More on that later in the year.