Enable Cognito threat protection

Amazon Cognito is the authentication layer in front of your customer-facing applications — sign-in, sign-up, password reset. Threat protection is an add-on tier that scores every login attempt for risk and blocks or challenges the suspicious ones automatically. Security Hub flags user pools running without it as Cognito.3 (and Cognito.4 for custom login flows) at Medium severity.

The billing model is simple: threat protection charges a small fee per monthly active user (MAU) above the free tier — typically a fraction of a cent per user per month. For most commercial applications the annual cost is a rounding error on the cloud bill. The relevant comparison is not "does this add to spend?" but "how does this spend compare to the cost of one account-takeover incident?" A single credential-stuffing breach typically drives tens of thousands of dollars in incident response, customer notification, and credential rotation — multiples of the annual threat-protection bill for an entire pool.

Security Hub flags two modes: AUDIT (logs risk signals but takes no action — fails the control) and ENFORCED (acts on risk — passes the control). The finance-relevant framing is that AUDIT is a free observation period, not a remediation. The decision to move to ENFORCED is almost always economically obvious once the cost-per-MAU is modelled against the breach cost it prevents. The rare exception is a pool serving only internal or disposable users where account takeover carries near-zero business impact — those justify a documented exception, not a blanket opt-out.

Jordan is the FinOps lead assigned to the security-and-cost review. The monthly dashboard shows three Cognito.3 findings — three user pools with threat protection either off or stuck on AUDIT. Before asking the team to fix everything, Jordan pulls the MAU count for each pool: one is the production customer-facing pool with 180,000 MAU, one is a partner portal with 4,000 MAU, and one is a dev/staging pool with a few hundred test accounts.

Jordan models the per-pool cost in five minutes: at the standard per-MAU rate, enabling ENFORCED on the production pool adds roughly $450/month; the partner portal adds about $10/month. The dev pool would add less than $2/month. Against that, Jordan pulls the incident-response estimate from the last breach postmortem in the company's risk register — the estimate for a credential-stuffing incident on the production pool is $85,000 minimum, not counting regulatory exposure under their HIPAA BAA.

The recommendation for the finance pack is straightforward: approve ENFORCED on all three, total incremental cost under $470/month, with the production pool carrying essentially all of it. The alternative — a documented exception for the dev pool — is also defensible, since a test-account takeover has near-zero business impact. Jordan records both paths as options and notes that any exception needs a written justification attached to the Security Hub suppression, so it's auditable.

The financial exposure from leaving threat protection off has two components: the direct incident cost and the regulatory tail. The direct cost of a successful credential-stuffing campaign on a production customer pool typically runs to tens of thousands of dollars in security-team hours, customer notification, credential rotation, and reputational damage — and that's before any contractual SLA penalties or customer churn. The regulatory tail is harder to bound: under SOC 2, HIPAA, or GDPR, a documented Security Hub finding left open at audit is evidence that you knew the control existed and chose not to enable it. Auditors treat that differently from a control you hadn't implemented yet.

The cost to close this finding is almost always small enough to make the risk register math one-sided. At standard Cognito pricing, enabling threat protection on a 100,000-MAU pool costs roughly $250/month — less than the burdened cost of a single engineer-hour of incident response. Framing it that way in the risk register converts the finding from a "security team issue" to a line item with a clear expected value: the annual premium versus the probability-weighted cost of one breach.

The one scenario where the math looks different is a pool serving only internal, low-privilege users or disposable test accounts. There the account-takeover blast radius is small, and a documented exception is a defensible decision. But that exception should be explicit — a recorded, reviewed justification attached to the Security Hub suppression — not an omission. Finance's role is to ensure every open Cognito.3 finding is either remediated or has a cost-and-risk justification on the record.

Every application that lets customers log in has a login endpoint, and every login endpoint is attacked. Credential stuffing — automated bots replaying leaked username/password pairs from other breaches — is one of the most common paths to account takeover. Cognito threat protection scores each login attempt and blocks the ones that look like an attack, without any code change in the application. Security Hub flags this as missing at Medium severity.

The executive question is simple: are the customer-facing authentication pools running with this control enabled, and is it set to ENFORCED rather than just AUDIT? AUDIT means you're watching attacks succeed without stopping them. The cost of enforcement is small — a fraction of a cent per active user per month. The cost of one successful account-takeover incident — response, notification, regulatory scrutiny — is almost always orders of magnitude larger. This is a control where 'not enabled by policy' is the only defensible answer; 'not enabled by oversight' is not.

At a mid-size SaaS company the CISO, Amara, used to answer "are we protected against credential stuffing?" with "Cognito handles authentication." After a Security Hub rollout surfaced three Cognito.3 findings, the honest answer became clearer: Cognito handles authentication, but the threat-scoring layer was off on two of the three pools, including the production customer pool.

Amara didn't need to understand the set-risk-configuration API call. She needed one thing: a commitment from engineering that all customer-facing pools would run in ENFORCED mode within two weeks, with a brief memo explaining why any pool left below that threshold was a deliberate, low-risk exception. The cost was negligible. The audit trail — showing that the finding was found, understood, and acted on — was the thing that mattered when the compliance team ran their next review.

That's the right frame for this control. It's not a complex technical decision; it's a governance check. Is the authentication layer in front of customers protected by policy, not by chance? A fast yes with documented exceptions is the healthy answer.

This control shows up at the leadership level because the impact of getting it wrong is customer-facing and externally visible. Credential stuffing attacks don't stay inside your perimeter — they result in customer accounts being accessed, data being exfiltrated, and customers finding out their account was compromised. That's a trust and reputation event, not just an IT ticket. Security Hub flags this at Medium severity precisely because the probability of attack is high (it is the leading attack vector on login endpoints) and the cost of a miss is large.

The cost of enabling the control is small enough that it almost never warrants a deliberate opt-out decision for customer-facing pools. The leadership question is not whether to enable it but whether it is enabled everywhere it should be and whether every gap is a documented choice rather than an oversight. A clean answer to 'are all customer login pools running with threat protection enforced?' is a one-minute confidence signal at the board level. An unclear answer is a risk that needs to be on the agenda.