AWS Cognito Signup Enrichment: A PLG Playbook for SaaS Teams on AWS

Cognito authenticates people. It doesn't tell you who they work for

AWS Cognito shows up constantly in SaaS products built by teams already living in AWS: Amplify apps, internal tools that grew into products, anything where the founding engineers didn't want to run a separate auth service. It handles sign-up, sign-in, MFA, and federation with SAML or OIDC identity providers, and it does it inside the same billing account and IAM boundary as the rest of the infrastructure.

What a Cognito user pool gives you by default is thin. A sub, an email, maybe a phone number, and whatever standard attributes you asked for at sign-up. Nothing in that record says which company the person works at, whether they're a decision-maker or an intern testing a free tier, or what a growth or sales team should do next. Two rows in the same user pool, one from a solo developer and one from a VP evaluating your product for a 400-person org, look almost identical until someone does the work of resolving them.

Cognito's federation options make this gap sharper in a specific way. When a signup comes through a SAML or OIDC connection to an enterprise IdP (Okta, Azure AD, Google Workspace), you already have strong evidence of the company. When it comes through email/password or a personal-provider social login, you have almost nothing. Most SaaS tools on Cognito see both paths, and treating them the same wastes effort on the easy case and under-resolves the hard one.

Where enrichment fits in a Cognito user pool

Cognito's Lambda triggers are the natural integration points, but they behave very differently and mixing them up causes real problems.

Pre sign-up runs before the account exists and is meant for validation: blocking disposable email domains, auto-confirming trusted federated users, checking an allowlist. It has a short execution window and blocks the sign-up flow while it runs. Don't call an external enrichment API from here. A slow third-party lookup adds latency to every signup, not just the ones you'll actually act on.

Post confirmation fires once the account is verified, which is the right moment to say "a new user exists, go find out who they are." Treat this trigger the same way as pre sign-up: keep it thin. Publish an event to EventBridge or SQS with the sub, email, and identity provider, then return immediately. Let a separate worker do the enrichment call.

Pre token generation runs on every token issuance, including refreshes, which makes it a poor place for enrichment logic but a good place to inject already-resolved data (an ICP tier, a company name) into the token claims once you have it, so your app doesn't need a separate lookup on every request.

Post authentication fires on sign-in, not just first sign-up. Some teams use it to catch behavioral signals, like a long-dormant account suddenly becoming active, but it should never trigger a fresh enrichment call for someone you already resolved. Repeated lookups on every login burn through enrichment credits for information that hasn't changed.

What Cognito already tells you

Before calling an external provider, pull what the user pool already has:

• identities (for federated users), which names the IdP a signup came through. A SAML connection tied to a known enterprise IdP is close to a confirmed company match before enrichment even runs.
• The hd claim on Google-federated signups, present when the account belongs to a Google Workspace domain rather than a personal Gmail account.
• email_verified, which is true by default for most federated providers but depends on your settings for password signups.
• Standard attributes like name and picture, populated automatically for social and enterprise federation, giving you something to display before any enrichment result comes back.

A SAML-federated signup from a known enterprise IdP barely needs enrichment for company identity, though it still needs ICP scoring and teammate discovery. An email/password signup with a Gmail address and nothing else is the case that needs full resolution, the kind of personal email enrichment that matches a private address to a real company using actual evidence instead of guessing from a domain that doesn't exist.

A signup enrichment playbook for Cognito

1. Branch on identity provider first

Split signups into three lanes at the Post confirmation event: SAML/OIDC federation (strong company signal, light-touch enrichment), Google Workspace or Apple Business federation (domain-based lookup), and email/password or personal-provider federation (full resolution needed). Routing all three through the same enrichment call wastes budget on cases that were already answered by Cognito's own federation data.

2. Keep triggers stateless and fast

Cognito Lambda triggers have execution limits and run synchronously in the sign-up or sign-in path. Anything that calls a third-party API, waits on a database write outside DynamoDB, or does real processing belongs in an async worker, not the trigger itself. Publish an event and exit.

3. Store enrichment results outside custom attributes when they don't fit

Custom attributes are useful for small values you need in the ID token, an ICP tier, a plan flag, but they're capped in count and size, and several attribute properties (including whether an attribute is mutable) can't be changed after the user pool is created. Keep the full enrichment payload, company profile, confidence score, discovered teammates, in DynamoDB or your application database, and mirror only the one or two fields your frontend actually needs into a mutable custom attribute.

4. Separate confidence from fit

A resolved company and a good-fit company answer different questions. Confidence says how sure you are about the match. Fit says how close that company is to your ICP. A federated signup from a known IdP might have near-perfect confidence but score low on fit if the company itself isn't a target account, and that combination should route differently than a low-confidence match to a great-fit company.

5. Run teammate discovery once fit clears your bar

Cognito user pools often accumulate several people from the same company over weeks, especially when a first user tries the product before inviting colleagues. Once a signup resolves to a company above your fit threshold, check the pool for other users on the same domain. That second and third signup is an expansion signal, not three isolated accounts to enrich independently.

6. Route to at least three lanes

High-confidence, high-fit signups go to sales-assist or a direct notification. Medium-confidence matches sit in a review queue instead of triggering automated outreach; a rep reaching out to the wrong person costs more than a short delay. Low-confidence or low-fit signups stay in self-serve, with the enrichment attempt logged so the record can be revisited if new signals show up later.

A concrete example

An infrastructure monitoring tool built on Cognito sees a signup through email/password with the address d.martinez@gmail.com, no federation, no company signal at creation. Two weeks later the same sub connects a production AWS account, invites a teammate, and hits the free-tier alert limit. None of those events retroactively improve the original enrichment result, the person still resolves to the same company with the same confidence, but together they're exactly the kind of usage signal that should push a "low confidence, monitor" record into "notify sales now." A pipeline that only re-checks identity confidence, and ignores product usage, will sit on this account for weeks.

Cognito enrichment checklist

• Enrichment triggers on Post confirmation, never on every Post authentication event.
• Lambda triggers stay thin: publish an event, let a worker handle the API call.
• SAML/OIDC federation and Google Workspace signups skip full resolution; email/password and personal-provider signups get it.
• Full enrichment payloads live in DynamoDB or your app database, not stretched across custom attributes.
• Confidence and ICP fit are tracked and reviewed as separate numbers.
• Teammate discovery runs automatically once a signup clears your fit threshold.
• Routing has at least three lanes: sales-assist, review queue, self-serve.
• Product usage events can raise urgency on an already-resolved account without re-running identity resolution.

Metrics worth tracking

Resolution rate specifically on email/password and personal-provider signups, since federated signups were never the hard case and blending the two numbers hides whether the real problem is solved. Time from Post confirmation to a usable enrichment result. Conversion rate from high-confidence, high-fit signups to a sales conversation or paid plan. And the number most teams don't track: how often a match a system marked "resolved" turns out wrong on manual review. If that climbs, tighten the confidence threshold before adding another provider.

Where this leaves Cognito-based teams

Cognito will keep doing what AWS built it for: authentication that stays inside your existing infrastructure and IAM boundary. Enrichment is a layer that sits next to it, turning a bare sub and an email into a company, a role, and a fit score a growth or sales team can act on before the account goes cold.

Groful runs this as a background workflow built for exactly this handoff: resolve Cognito signups by identity provider, including the email/password accounts most tools ignore, discover teammates already inside the account, score everything against your ICP, and push results to your stack through API and webhook integrations. Compare the approach on Groful vs. Clearbit, check pricing, or get in touch to run a batch of your own Cognito users through it before wiring anything into production.