Connect Voice ID Ended May 20, 2026: What to Migrate To

As of October 28, 2026, Amazon Connect Voice ID has been retired for five months. AWS stopped taking new customers on May 20, 2025, and ended support on May 20, 2026. Any flow that still contains a Check Voice ID block is branching on a service that is no longer there.

This is the migration plan: what exactly ended, how to find every flow that references Voice ID, which replacement fits which risk tier, how to cut over without locking customers out, and how to confirm your stored voiceprints are deleted. The hub page Amazon Connect consulting has the short version.

Each option is labeled. Native means a Connect or AWS building block you assemble. Partner means a third-party product from AWS Marketplace. Custom engineering means code you write and run. The inventory script and its test are in the artifact folder.

Modeled plan (not a cited client): FactualMinds has no published Voice ID migration engagement. The dates and parameter names come from AWS documentation read on October 28, 2026. The one thing run is the mocked test of the scanning script. It does not touch a live instance.

What ended, with dates

AWS’s end-of-support page gives two dates, and teams often blur them.

The Voice ID API reference pages carry the same end-of-support notice. So does the Set Voice ID block page.

The page does not describe what a flow does at run time when it hits a Check Voice ID block after the cutoff. It does not say when, or whether, AWS removes domains you never deleted. Do not plan around either. Test in a non-production instance, and treat the Error branch of every Check Voice ID block as the live path until you have replaced it.

What Voice ID did in your flows

You need to know what each block was deciding before you can replace it. Voice ID used two flow-language action types.

• Set Voice ID is stored as an UpdateContactData action. It turns on audio streaming and sets the authentication threshold (default 90), the response time (5 to 10 seconds), the fraud threshold (recommended starting point 50) and the watchlist. A Set contact attributes block next to it supplied the CustomerId, which Voice ID used as the speaker id.
• Check Voice ID is the CheckVoiceId action. Its CheckVoiceIdOption is enrollmentStatus, voiceAuthentication or fraudDetection.

The branches are the part to preserve. voiceAuthentication returned Authenticated, Not authenticated, Inconclusive, Not enrolled or Opted out. fraudDetection returned High risk, Low risk or Inconclusive. Enrollment needed about 30 seconds of speech and authentication about 10 seconds. Those numbers are why many IVRs had a “keep talking” step before the check.

Two consequences follow:

1. Passive authentication hid the cost. Callers never typed anything. Any replacement that asks the caller to do something is a visible change, and you should expect handle time to move. We have no number for how far.
2. The fraud signal is a separate dependency. If you used fraudDetection against a watchlist, OTP does not replace it. That needs its own decision, and the partner route is the only one in this post that offers anything like it.

Step 1: find every flow that references Voice ID

Start with an inventory, because the block can sit in flow types you rarely open: customer queue, whisper and transfer flows are all supported places for Set Voice ID.

The script lists flows with ListContactFlows, fetches each with DescribeContactFlow, and scans the Content JSON for the two action types above. The Connect client is injected, so the same code runs against the real SDK or the mock in the test. The matcher is also an exported object, in case AWS renames a key.

The call below is a Node 24 ESM snippet from the artifact. It assumes you built client from @aws-sdk/client-connect as the CLI section of the script does.

import { findVoiceIdFlows } from './find-voice-id-flows.mjs';

const { scanned, flows, errors } = await findVoiceIdFlows(client, instanceId);
// flows: [{ id, name, type, state, actions: [{ id, type, detail }] }]
// errors: flows that could not be described or parsed. Not empty means the inventory is incomplete.

The rule that keeps false positives down: UpdateContactData also sets ordinary things like the contact name, so the script only reports it when Parameters contains a Voice ID key such as IsVoiceIdStreamingEnabled or VoiceAuthenticationThreshold. A block that sets streaming to "FALSE" is still reported, since it is still a Voice ID reference.

What it does not see: flow modules, Lambda functions that read the Voice ID result from contact attributes, Contact Lens rules, and agent-side CCP configuration. Search those by hand. Run the scan in every Region and every instance, and run it again after cutover. The exit criterion is zero flows.

Step 2: tier the journeys

Do not pick a factor for the contact center. Pick it for the thing the caller is asking to do.

Voice ID is typically used in front of tier 1 and 2 journeys. Many of those can move to a lighter factor. Tier 3 should not rely on any single passive or one-code check, which is true of Voice ID as well.

Step 3: choose the replacement

Option A: one-time passcode over End User Messaging (native building blocks, custom engineering)

AWS’s own end-of-support page points to a do-it-yourself passcode check with AWS End User Messaging SMS, and to a messaging blog on one-time-password architecture. The pieces are standard Connect and AWS parts:

• A Lambda generates a code, stores only a hash with a short expiry and an attempt counter, and calls the End User Messaging SMS SendTextMessage operation with message type TRANSACTIONAL.
• The flow’s Get customer input block collects the digits by DTMF. A Lex bot can collect them by voice, but DTMF is simpler and avoids speech-recognition errors on digits.
• A second Lambda checks the entry and returns a flat result, as in the Shopify lookup. Keep it inside the 8 second synchronous Lambda budget and make it return a fallback instead of throwing.

The AWS blog notes that the same platform can deliver codes by voice call, email and other channels as well, which gives you a fallback for callers who cannot receive SMS.

Four design rules decide whether this is safe:

1. Send to the number on file, not the caller ID. Caller ID is not an identity, and an attacker can spoof it. Look the customer up first (Customer Profiles or your CRM) and send to the stored mobile.
2. Make the code short-lived and single-use. Pick an expiry and an attempt limit, and log both. After the limit, hand off to an agent.
3. Handle the asynchronous gap. The SMS can arrive after the prompt has timed out. Say what is happening, wait, and offer a resend once.
4. Have a path for no mobile. Some callers have a landline or an outdated number. Route them to knowledge-based or agent verification, not a dead end.

The risk is well known: SIM swap and number porting move the code to the attacker’s phone. That is why this option suits tiers 1 and 2, not tier 3.

Option B: knowledge-based questions (native, weak)

You can ask for a postcode, a date of birth, the last four digits of something, or an order number with Lex or DTMF input. This is the cheapest option and it is the weakest. The answers sit in data-broker files, past breach dumps and on packing slips. NIST’s digital identity guidance advises against knowledge-based questions as an authenticator.

Use it as a second signal next to another one, never alone. The order-number problem is the same one the Shopify post describes: it is printed on confirmation emails.

Option C: Connect’s own customer authentication (native, chat only)

Connect has an Authenticate Customer block, configured through the AuthenticateParticipant flow action. It sends a chat customer to an Amazon Cognito sign-in, then creates or updates a customer profile. It needs customer authentication enabled on the instance, a Cognito user pool and Customer Profiles.

It does not help the voice channel. AWS marks voice as unsupported, and a voice contact takes the Error branch. Do not choose it as the Voice ID replacement. Use it for the chat journeys on the same instance, where it is a stronger answer than a code.

Option D: a third-party voice biometric (partner)

AWS’s end-of-support page names Pindrop as an example of an AWS Partner solution on AWS Marketplace. We can verify that AWS names it in that page. We did not evaluate it, we do not know its integration model, accuracy or price, and this is not a recommendation. Other vendors list Connect integrations too, and we did not verify them for this post, so we name none.

What to check in any partner review:

• How audio gets to the vendor. Where it is sent, over what path, and whether you can stream only the authentication portion.
• Enrollment. Passive enrollment on the first call is how Voice ID worked. A partner may differ.
• Fraud signal. Whether it returns a risk score you can branch on, as fraudDetection did.
• Data location and deletion. Where voiceprints live, who can delete them, and how you prove it.
• Contract terms. Biometric consent language, retention, breach notice and subprocessors.

Pricing for partner products is on the Marketplace listing or by quote. We have no published figure to quote.

When not to replace it with biometrics

Voice biometrics is the right tool for a narrow case: high call volume, repeat callers, high-value actions and a risk team that will watch the fraud signal. It is the wrong tool in these cases:

• Low call volume or mostly new callers. There is nobody enrolled, and enrollment takes about 30 seconds of speech.
• Tier 0 and 1 journeys. An OTP or no check at all costs less and carries less regulatory weight.
• Callers on poor lines or with speech differences. Voice ID’s own guidance says a sick caller in a car scores lower than a healthy caller in a quiet room. Raising the threshold raises false rejects, and AWS says that above 95 agents verify nearly every customer.
• A legal regime you have not checked. Voiceprints count as biometric data in several jurisdictions, including under Illinois’s BIPA, with consent, notice and retention duties. We are not lawyers. Ask yours before you collect new voiceprints, especially for callers in more than one state or country.

Voiceprints and data deletion

The AWS page gives a specific procedure for your Voice ID data:

1. Use ListDomains with DescribeDomain to list every domain in the account.
2. For each domain, ListSpeakers downloads the enrolled callers and ListFraudsters the registered fraudsters.
3. Call DeleteDomain to delete all customer data in a domain. Do it for every domain, in every Region, in every account.

Order matters. Export what you must keep for fraud or legal reasons first, then delete. Keep the API responses as evidence. Because AWS also says Voice ID resources are not reachable after May 20, 2026, a call may fail on a domain you left behind. If it does, do not assume the data is gone. Open an AWS Support case, ask for written confirmation, and record it in your retention register.

Also update your privacy notice. If you told callers their voice was used to authenticate them, that statement is now wrong or at least stale.

Migration plan

Since the old service is gone, a parallel run may have nothing to compare against. Run it against the Error branch behavior you have been living with since May. Measure the new path on its own: completion, drop-off at the code entry, handoff rate and handle time.

Fraud and risk trade-offs

• OTP moves the weak point to the phone number. SIM swap and porting beat it. Pair it with a recent-change check: a number changed in the last few days drops the caller to a stricter path.
• KBA looks like a control but passes for anyone with the data. Never use it alone above tier 1.
• Lockout is an attack surface. An attacker who triggers codes to a real customer’s phone annoys the customer. Rate-limit by customer and by calling number.
• Agents are part of the system. Show the agent what was verified and how. A flow that authenticates and then makes the agent ask the same question again has not saved anything.
• Removing a passive check is a UX change. Fewer callers will pass silently. Plan for the additional minutes.

Testing

• Scanner. The artifact’s three tests use hand-written flows in the documented shape. They prove the matcher finds both action types, ignores a plain UpdateContactData, reports an unparseable flow without crashing, and accepts an override. They do not prove anything against a live instance.
• OTP flow. Test expiry, wrong code, third wrong code, resend, a number with no mobile on file, and SMS delivery delayed past the prompt.
• Failure paths. Force the Lambda to time out. The caller must reach an agent, not silence.
• Load. SMS and Lambda concurrency limits differ by account. Check yours before a campaign day.

Costs (published prices, checked October 28, 2026)

• Connect voice: the Connect pricing page lists $0.038 per voice minute for Connect Customer, with telephony charged separately.
• End User Messaging SMS: AWS bills per message at a rate set by the destination country, plus one-time registration and monthly number-lease fees that vary by country. We quote no single number here. Read the pricing page for your Regions.
• Partner biometrics: not published here. Ask the vendor.

Arithmetic, not a measurement: an OTP step that adds 45 seconds to a call adds about $0.0285 of Connect voice at the list rate ($0.038 times 0.75 minutes), before telephony and before the SMS. At 100,000 authenticated calls a month that is about $2,850 of extra voice minutes. That is the figure to weigh against a biometric subscription, with agent time on top of it.

What to do this week

1. Run the inventory in every instance and Region. Fix any errors first.
2. List which journeys read voiceAuthentication and which read fraudDetection.
3. Tier them, and decide which journeys need no check at all.
4. Open an AWS Support case about undeleted Voice ID domains, and ask for written confirmation.
5. Build the OTP subflow with its fallback first, then the happy path.
6. Ask legal about voiceprint consent and retention before any biometric partner call.

FactualMinds is an AWS Select Tier Services Partner. If you want this migrated across your flows and tested end to end, start at Amazon Connect consulting or contact us.

What this post doesn’t cover

• Live results. No false-reject, completion, handle-time or fraud numbers. We have no migration engagement to report.
• The OTP flow itself. The artifact is the inventory script, not a finished authentication subflow.
• Partner evaluation. We did not test any vendor.
• Legal advice. Biometric and telecom rules differ by place. Use counsel.
• Chat and email authentication design beyond noting the Authenticate Customer block.
• Agent-side use of authentication results: see Customer Profiles and a custom agent UI and Connect AI agents for FAQ and self-service.

Related reading

• Amazon Connect Consulting
• Connect + Shopify: order lookup inside 8 seconds
• Connect AI agents for FAQ and self-service
• Customer Profiles and a custom agent UI

Frequently asked questions