Designing SMS MFA in Keycloak for Large User Bases

In a small internal system, integrating SMS with Keycloak can be relatively straightforward: an authenticator, a connection to the messaging provider, and basic protection against repeated sends. In a large public system, the same mechanism becomes part of a much broader security and operations problem.

Requests are processed concurrently by multiple Keycloak instances, attacks may run over long periods, traffic sources change, registration and login carry different risks, and false positives can affect a significant number of legitimate users.

This article continues the topic covered in our guide to building a custom SMS authenticator in Keycloak. It does not describe one environment or prescribe a ready-made set of thresholds. Instead, it covers the areas worth examining when SMS MFA needs to operate at scale.

SMS pumping does not need to compromise an account

Traditional MFA threat analysis focuses on account takeover: OTP brute force, phishing, session theft, or SIM swapping. An SMS gateway introduces another risk: SMS pumping, also known as SMS toll fraud or Artificially Inflated Traffic.

The attacker does not need to log in. It is enough to abuse registration, account recovery, or code-resend processes to generate paid messages. One SMS costs very little, but sustained traffic can quickly become a security, availability, finance, and customer-support problem.

Protection should therefore not be evaluated only by the number of blocked requests. Other important considerations include:

• how quickly the financial impact can grow,
• the maximum reach of an incident,
• how quickly the operations team can respond,
• the effect of controls on legitimate users.

It may not be possible to stop every suspicious request. A well-designed system should still make automation harder, constrain the impact of abuse, and provide enough information for an effective response.

One rule cannot describe the whole risk

A simple cooldown or a control tied only to the phone number can be a useful starting point. It does not provide a complete picture. Automated traffic can use many numbers, accounts, sessions, and IP addresses, while remaining below any single threshold for an extended period.

Protection should consider the context of the request rather than one counter. Relevant factors may include:

• whether the user and phone number are already known,
• the source and repetition pattern of the traffic,
• the stage of the authentication process,
• the destination and cost of the message,
• previous successful and failed operations,
• the current condition of the service as a whole.

This does not mean that every signal should automatically block a message. Some signals may only raise the risk level, require additional verification, or contribute to a decision when combined with other information.

The policy should follow the organisation’s actual traffic profile. Controls that are too permissive will not constrain the cost of an attack. Controls that are too aggressive will reduce registration and login success. At scale, even a small false-positive rate can create a significant operational problem.

Registration and login have different risk profiles

From the integration’s perspective, each operation may end with an SMS code being sent. From a risk perspective, registration, login, phone-number changes, and account recovery are different processes.

During login, the system usually knows the account, associated number, and previous authentication history. Registration provides less context and is easier to automate. A phone-number change concerns a known user but introduces a new identifier. Account recovery has a particularly high impact on account security.

A single policy for all these situations simplifies configuration, but it may be too strict for some users and too lenient for others. A better starting point is the risk of the complete process: which information has already been verified, what effect sending the message has, and which additional signals are available.

Exceptions require the same care. A successful authentication is a valuable signal, but it should not automatically remove all history that remains relevant to abuse prevention.

External risk assessment as an additional layer

The local system understands business rules and previous user behaviour, but it may have little information about a new number or traffic originating outside the organisation. Specialised anti-fraud services can supplement that assessment.

One example is Google Cloud SMS Defense, which returns an SMS toll-fraud risk assessment before a message is sent. This signal can support a decision, particularly when local history is still limited.

External scoring should not be the only control. The service can be unavailable, return an incorrect assessment, or lack knowledge of the specific process. The architecture must define what happens when no response is available and divide responsibility appropriately between local rules, cost controls, and external risk signals.

Distributed environments change how state is handled

Keycloak commonly runs as a cluster of multiple instances. A protection mechanism that relies only on the memory of one process does not see the complete traffic picture and may make decisions using incomplete data.

State used for risk decisions should be available where the decision is made and behave predictably during concurrent requests, restarts, and topology changes. Teams also need to decide which information is short-lived and which should persist for longer.

Keycloak uses Infinispan as its caching layer in clustered environments. The Keycloak caching documentation describes distributed caches used for data including sessions and failed-login detection. Custom extensions can take this mechanism into account, but the choice of state store should follow requirements for durability, multiple regions, failure handling, and supportability.

Concurrency is a separate concern. When several requests arrive almost simultaneously, an independent check followed by a later state update can produce an inconsistent decision. Operations that affect whether a message can be sent should account for atomicity, idempotent retries, and ambiguous responses from the SMS provider.

The policy must be configurable and operational

Values that govern protection should not be hard-coded. User traffic, provider pricing, and attacker behaviour change faster than the application’s release cycle.

The engineering team should provide safe configuration mechanisms, initial values, and guardrails against accidentally dangerous settings. The process owner, security team, and operations team should evaluate changes together using traffic data and accepted risk.

The way changes are introduced also matters. Policy updates should be auditable, testable, and easy to roll back. Otherwise, a response to an incident can itself cause an availability problem.

Observability across security, cost, and user experience

A protection mechanism cannot be tuned safely without data. Monitoring should cover three perspectives:

• security: changing traffic patterns and reasons for rejection,
• cost: message volume and spending over time and by destination,
• user experience: completion rates, delays, and false positives.

Metrics should not contain phone numbers, complete IP addresses, or other data that creates privacy risk or uncontrolled cardinality. Properly protected logs and correlation identifiers are better suited to analysing individual incidents.

An increase in rejected requests can indicate an attack, but it can also reveal a configuration error, provider failure, or a change in legitimate user behaviour. An alert should therefore begin an investigation, not automatically confirm fraud.

Key lessons

SMS MFA in a large system is not only an authenticator feature. It is a process combining account security, cost control, distributed-system reliability, and user experience.

The most important principles are:

1. Assess the context of the complete process, not only one phone number or request.
2. Distinguish the risks of registration, login, phone-number changes, and account recovery.
3. Treat external fraud scoring as an additional signal rather than the sole source of a decision.
4. Design state and concurrency for a clustered Keycloak environment.
5. Tune protection using security, cost, and legitimate-user behaviour together.

The hardest part is not building the most restrictive protection possible. It is constraining abuse while remaining practically invisible to people using the system correctly.

If you are planning or auditing a production IAM environment, talk to INERO’s Keycloak team. We can help assess MFA architecture, operational risks, and an operating model suited to your environment.