Your client portal is the central nervous system of a growing business—until nobody uses it. We built a portal for a Southeast Asian financial services firm that achieved 12% weekly active users after six months. Every email reminder, password reset workflow, and UX tweak barely moved the needle. The bottleneck wasn't the portal itself. It was the login ceremony: create a password, remember it, reset it when you forget, repeat. After we replaced passwords with SMS OTP (one-time password), weekly active users jumped to 28% in 30 days. Here's exactly what we did, how we stayed compliant, and how the adoption curve actually formed. Why Passwords Failed and OTP Succeeded The client had deployed a conventional portal: username, password, optional two-factor authentication. Early analytics showed a clear pattern. Users would land on the login page, attempt to sign in, fail, request a password reset, wait for the email, click the reset link, set a new password, and finally log in. Half of them never completed the sequence. The friction wasn't the portal features—it was the prerequisite to reach them. Password managers existed, but most of the user base (field staff, contractors, small business owners) didn't use them. Recovery flows sent email reset links. Email is asynchronous; links expire; users forget they requested a reset. The entire flow assumed users valued security more than convenience. For internal tools, that works. For a client-facing portal where adoption drives engagement, it doesn't. SMS OTP inverts the equation. A user enters their phone number, receives a six-digit code via SMS within seconds, and lands in the portal. No password. No reset flow. No account recovery ritual. The friction dropped to near zero. We also added a silent fallback: if SMS failed, the user could still request a password reset, but the default path was OTP. The Implementation: Twilio Integration and Session Logic We used Twilio to send SMS codes because it offers per-country carrier routing, delivery guarantees, and simple REST APIs. The flow looked like this: User enters phone number on the login page. The portal looks up the number against the customer database and confirms it's linked to an active account. Portal generates a six-digit code (alphanumeric, expiring in 10 minutes) and stores it in a server-side cache with a hash of the phone number. We never logged plaintext codes. Twilio sends the SMS via the appropriate regional carrier. Delivery confirmation is logged but doesn't block the user. User receives SMS and enters the code on the confirmation page. The portal compares the entered code against the cached hash, confirms a match within the 10-minute window, and establishes a session. Session cookie is set with a 30-day expiry for returning users. On the next visit within 30 days, the user doesn't need to re-authenticate. The engineering was straightforward; the operational complexity was elsewhere. Twilio's API is reliable, but SMS delivery can fail. Networks go down. Carriers rate-limit. We needed a fallback that didn't send users to a dead end. Fallback When SMS Fails SMS delivery in Southeast Asia is 98%+ reliable on regional carriers, but the remaining 2% happened to our users. We built two fallbacks: First fallback: If the SMS doesn't arrive within 30 seconds, the portal displays a message: "Code not received? We'll send you a password reset link via email." The user can click through to the traditional reset flow without losing the session attempt. This preserved access for the unlucky 2% and gave users agency. Second fallback: We configured Twilio to retry delivery once on a different carrier route if the first attempt timed out. This caught another 0.8% of failures silently, so users never saw the delay. We also added a manual override for support. If a user called in after three failed SMS attempts, the support agent could generate a one-time login link valid for 15 minutes and send it via email. In 30 days, we used this path for 12 users across a base of 300. Not zero, but negligible. Compliance: PDPA and Data Residency SMS OTP involves storing phone numbers and sending them to a third-party API. In Malaysia, Singapore, and Indonesia, that raises three compliance questions: PDPA (Personal Data Protection Act), data residency, and retention rules. PDPA consent: We added explicit consent language on the login page: "We'll send you a one-time code via SMS. Your phone number will be used only for login security and is never shared with third parties." During account creation, we'd already collected phone numbers, so we sent a separate PDPA notification explaining the new login method. We logged all consent events and kept a record that users had agreed. Third-party processor (Twilio): Twilio's Data Processing Addendum (DPA) was signed before any SMS was sent. We confirmed that Twilio stores SMS logs in the US (not in Malaysia/Singapore/Indonesia), but because they act as a processor under our instructions (n