Contact Center Authentication

Kelley describes her experiences calling in to 30 different company’s call centers: what info they requested to authenticate her, what they did well, what they did poorly, and recommendations for designing more secure call center authentication protocols.

Kelley Robinson, Dev Advocate, Account Security, Twilio twitter, linkedin
abstract slides video

Kelley describes her experiences calling in to 30 different company’s call centers: what info they requested to authenticate her, what they did well, what they did poorly, and recommendations for designing more secure call center authentication protocols.

Research parameters

Kelley chose companies for which she had an existing account with at least some personal info tied to it (e.g. orders, her address) that had an available USA customer support phone number that accepted inbound calls.

She mostly tested information gathering (read), but did some limited actions and account changes (write). In several cases, attempting to change attributes of an account triggered additional security checks.

Kelley ended up contacting 30 companies, including United, Netflix, Apple, Hyatt, conEdison, Lemonade, Walmart, Chase, Mattress Firm, and Comcast.


Getting in touch with companies over the phone can generally be grouped into the following categories:

  1. They provide a customer support number (e.g. Home Depot, Comcast, State Farm)

  2. They have a “Call me” feature (e.g. Walmart, Amazon, Verizon)

  3. No phone number provided (e.g. Facebook, Lyft)

Kelley focused on the first category in this research.

While most companies provided an Interactive Voice Response (IVR) system that lets you specify what you’re aiming to do via voice and/or keypad presses, the path you select rarely matters if you end up talking to a human agent.

Companies tend to do identification in one of the following ways:

  1. Automated with the phone number you’re calling from (caller ID), if your account is tied to your phone number.

  2. Automated with info a company-specific number you provide, like an account number, insurance ID, credit card number, etc.

  3. Manual with an agent, which is what this talk focuses on.

Identifying you is not the same as authenticating you!

Establishing identity can be done with personal information, such as your date of birth, but this information tends to be static and searchable online. Many people could find out this information.

Authenticating is proving you that you are actually the person you claim to be, usually via a secret, such as a one time code sent to your phone.


At a high level, some companies did very well, others don’t vet you very strictly, for example, they just ask for your name and date of birth, which can be easily found.

The identification methods used by the companies Kelley contacted. Note that the most popular types on the left are more related to ‘identify’ than ‘authentication’, in that they’re static and/or and semi-public. Overall, not the type and rigor of attributes we’d like to see from companies.

Kelley noted that one shipping company asked for her password, so they could log in as her in their system 😅.

Kelley had just moved when she was doing this research, so sometimes she’d ask services for the address on her account to ensure it had been updated. Some wouldn’t provide this info, but some would. This is a problem because some services use your address to identify you, so when a company gives this info out they’re making your other accounts more vulnerable to account takeovers, and potentially putting you at personal risk.

Moar stats plz
I liked the content, structure, and the fun presentation style of this talk. If I could provide one piece of feedback, it would be that I would loved to see more stats on what Kelley observed across all of these companies.

Here we see the types of identity info companies asked for, but what were the identity info combination companies tended to ask for? How many companies asked for one vs more than one form of ID? How many companies leaked aspects of your account info, and what info? How many companies allowed state changing account actions with what level of identity/authentication? How many companies required additional info for state changing actions, and what info did they ask for? Did any of these vary by company vertical, and what were the trends?

The Good: Actually Authenticating Users

Some services did really well, providing users one time codes for authentication and refused to disclose personal information.

Once you’re logged in, Netflix has this Service Code button that provides you a 6 digit code that you can then provide to a service rep to authenticate you.

Stripe provides an easy built-in way to authenticate yourself to Stripe, and vice versa. I think this is awesome, and not something I see commonly from companies.

The OK

Most companes were here - room for improvement but overall positive, doing things like:

  • Recognizing the phone number you’re calling from.

  • Verifying multiple forms of personal information.

    • If you’re not going to true authentication, at least require the caller to have multiple forms of information.

  • Prompting with relevant account actions.

For example, the automated intro when calling in to United:

Welcome back, Kelley. I see you’re flying from LA to Newark Liberty today, are you calling about that trip?

Of course, there’s some risk here about revealing info about her travel plans, but that is ephemeral. There were some utility providers that when she’d call would prompt with, “Hi Kelley, are you calling about your account at 123 Main Street Apartment 3?”

Recommendation: Prompt users with relevant account actions they can take, but try to not to give away too much info about them.

The Bad

The process followed by these companies would allow successful phishing with minimal effort:

  • Only asking for one form of identity, for example, looking up your account by phone or email and asking no additional questions.

  • Identifying callers via easily accessible public information (e.g. phone number, email address, date of birth).

  • Requiring a Social Security Number.

    • This is not an authenticator! Many companies treat this as a secret but it’s not. SSNs have been leaked in many breaches, and they were issued serially prior to June 25, 2011.

The… oh… oh no

  • Giving out identity information. This was more common than she would like.

  • Allowing account changes without authentication.

  • Asking what phone number or email address to send an authentication token to 😆.


Alright, so what can we do to build more secure contact center authentication protocols?

Unify Authentication Systems

Use the same rigor for authentication over the phone as you do on your website, and honor user settings for things like 2FA.

Build Guardrails for Agents

Agents want to be helpful, and most don’t have anti-phishing training. We can design the systems and processes they use such that they can’t accidentally give out too much information about a users’s account.

  • Limit caller information available to agents.

    • If a user isn’t asking about address info, then don’t show it to the agent.

  • Only expose information after a caller is authenticated.

    • Thus a user’s info can’t be leaked until we’ve proven it’s them.

  • Have a small subset of agents that have access to do the most sensitive actions, who have undergone social engineering training, who are passed along the potentially dangerous calls.

  • Do a risk assessment using provided identity.

    • You can do things behind the scenes to detect fraud that’s transparent to the user. For example, there are services that can provide reputation/fraud info related to specific phone numbers or email addresses.

Provide guardrails for agents so that they can’t accidentally share info they shouldn’t.

Of course, there are trade-offs in building these guardrails - it can be a worse user experience, and it can make customer service calls longer, which increases cost.

Consider Your Threat Model

Reflect on what are you allowing people to do over the phone. If you can’t implement true authentication, limit the sensitive actions that can be taken, and instead direct users to your website.