What breaks is number verification, device binding, and account recovery. If teams remove SMS from login but leave onboarding unchanged, they often discover that the first proof of control still depends on the same channel they no longer trust. That creates a gap between customer creation and secure authentication.
Why This Matters for Security Teams
Removing SMS OTP without redesigning onboarding is not just an authentication change. It changes how an organisation proves control of a phone number, binds a new device, and restores access when the primary factor is unavailable. If those steps are left implicit, the team often replaces a visible risk with a hidden one: account creation still depends on a channel that is no longer accepted for login.
That gap matters because onboarding is where trust is first established. When verification is weak or inconsistent, attackers can exploit fallback paths, help desk shortcuts, or delayed recovery workflows to take over fresh accounts before normal monitoring matures. This is especially dangerous for regulated services that must demonstrate customer due diligence, such as the identity assurance expectations reflected in the FATF Recommendations — AML and KYC Framework.
NHI Management Group has documented how weak credential handling can cascade into wider compromise, including the Schneider Electric credentials breach, where identity and access weaknesses became an operational security issue. In practice, many security teams discover onboarding failures only after recovery abuse or account fraud has already occurred, rather than through deliberate testing of the new flow.
How It Works in Practice
When SMS OTP is removed, teams need a replacement for three distinct functions: verifying possession, binding the device or session to that verified channel, and enabling step-up recovery without reusing the same weak proof. If the new onboarding flow does not define each function explicitly, users may still be admitted through legacy logic, customer support workarounds, or silent fallback rules.
A sound replacement flow usually separates initial proof from ongoing login. Common patterns include email plus device attestation, passkeys, document-based verification, or risk-based step-up that is evaluated at runtime rather than assumed at enrollment. The important point is not which factor wins the debate, but that the onboarding decision and the login decision are different controls. This is why current guidance from identity and fraud practitioners increasingly favors layered verification, rather than simply swapping one factor for another.
- Make number verification explicit if the phone number is still a business identifier, even if it is no longer a login factor.
- Bind the account to a newly enrolled authenticator or device during onboarding, not after the first successful login.
- Separate account recovery from initial registration so one compromised channel cannot satisfy both.
- Log and review fallback paths, especially manual review and support-driven resets.
For NHI-heavy environments, the same principle applies to machine accounts and service onboarding: proof of identity must be paired with lifecycle controls, short-lived secrets, and revocation. The Ultimate Guide to NHIs shows why lifecycle discipline matters, and the risk becomes more acute when secrets are reused across onboarding and recovery. These controls tend to break down when legacy SMS logic remains in place for account recovery because the organisation has removed OTP from login but not from the underlying trust model.
Common Variations and Edge Cases
Tighter onboarding often increases friction, requiring organisations to balance fraud resistance against conversion and support burden. That tradeoff becomes more visible when users lose access to their phone number, change devices, or onboard from a new geography, where a rigid replacement for SMS can block legitimate signups.
Best practice is evolving, and there is no universal standard for this yet. Some environments treat a phone number as a contact attribute only, while others still need it as part of fraud scoring or recovery. The key is to avoid assuming that “no SMS login” means “no SMS anywhere.” In some cases, SMS may remain acceptable for notification or low-risk confirmation, but not as the sole proof of control. In higher-risk journeys, organisations should prefer stronger verifiers and step-up checks aligned with the business impact of account creation.
Edge cases also appear in delegated onboarding, shared phones, and enterprise enrolment where a person is not the only actor involved. If support teams can override identity proof too easily, the new flow may be easier to attack than the old one. That is why the Ultimate Guide to NHIs emphasis on visibility and rotation is relevant here too: onboarding breaks down fastest when the organisation cannot explain who or what was trusted, when, and on what evidence. In practice, the riskiest failures show up in recovery and exception handling, not in the primary happy path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Addresses identity proofing and access establishment during onboarding. |
| NIST SP 800-63 | IAL2 | Relevant to identity proofing when replacing SMS-based verification. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers lifecycle controls when onboarding and recovery share weak trust paths. |
| NIST AI RMF | MAP | Useful for mapping onboarding risks and fallback abuse in identity journeys. |
| NIST Zero Trust (SP 800-207) | AC-1 | Supports removing implicit trust from onboarding and recovery paths. |
Define onboarding proofing steps and verify every new account against documented access criteria.
