Your clients own passwords they won't reset. They forget them. They use the same one everywhere. So they stop logging in. A 40% adoption rate sounds normal until you realize it means most of your service delivery visibility, invoice history, and contract access lives outside your portal—in your team's email, their paper notes, and your recurring support calls. SMS passwordless login fixes this in 48 hours and lifts adoption to 80%. We'll map the implementation. Why passwords kill portal adoption—and why SMS changes the math Portal adoption fails for three overlapping reasons: friction at entry, friction at recovery, and no perceived value without entry. Passwordless authentication removes the first two. Password friction is real. A study of 500+ SMBs showed 47% of portal access attempts failed on first login—wrong password, forgotten reset, expired link. Of those, 62% never tried again. SMS OTP removes password reset entirely. No recovery flow. No account lockouts. No 'your password must contain a number and a symbol'. Clients receive a 6-digit code, enter it once per session, and land inside. That's it. The second friction is friction from friction. If login is painful, support gets worse. Clients call asking for password resets. Your team spends 3 minutes per reset. At 200 monthly portal users and a 5% monthly reset rate, that's 30 resets, 90 minutes, every month. SMS passwordless deletes that cost. Third, SMS triggers faster. Email OTP lands in secondary inboxes, spam folders, or hours later. SMS lands on the screen in seconds. A/B tests across five client portal platforms showed SMS OTP increased same-session completion by 34% versus email OTP. SMS feels closer to native app login—no context switch, no email client, just the portal and the phone in their pocket. 40% adoption with passwords. 80% adoption with SMS OTP. The gap is real. The implementation is fast. The cost is marginal. Architecture: SMS OTP flow in three layers A passwordless SMS login system has three moving parts: the client-facing portal, the OTP generation and delivery layer, and the session management layer. Here's how they stack. Layer 1: Client initiates login Client lands on portal, enters email or phone number. No password field. The portal validates the identifier against your client list and triggers an OTP request to your backend. If you're using Orin CRM , that client data is already there—phone number synced from signup, contact record live. No duplication. Layer 2: OTP generation and SMS delivery Three solid options: Twilio, Vonage, or AWS Cognito with Amazon SNS. Each scales to 200+ monthly users without hiccup. Twilio: Most straightforward. $0.0075 per SMS, no monthly minimum. Generate a 6-digit code server-side, fire it via Twilio's API, log the send. Twilio handles delivery and carrier partnerships. Uptime 99.95%. Setup: 15 minutes (API key, phone number purchase, code snippet). Vonage: Cheaper at $0.004 per SMS in many regions. Slightly more rigid API surface, but identical uptime and delivery speed. Good if your client base is outside North America. AWS Cognito + SNS: If you're already on AWS, this consolidates identity, MFA, and SMS in one service. Cognito handles the session layer automatically. Setup is longer (30 minutes) but you own the entire identity stack. Cost is opaque—bundled into AWS spend, but typically $0.005–0.008 per SMS at your volume. For 200 monthly users, assume 3 OTP attempts per user per month (first login + one retry + one password-recovery scenario). That's 600 SMS per month. Twilio cost: $4.50. Vonage: $2.40. AWS Cognito: buried in your existing AWS bill, likely $3–5. The cost is not the decision maker. Speed is. Layer 3: Session validation and portal access Client enters the 6-digit code. Your backend validates it against the stored OTP (timestamped, single-use, 10-minute expiry). If valid, create a session cookie or JWT token. Client is logged in. No password ever stored. No password ever reset. Session lifetime matters. Set it to 30 days for service businesses—long enough that clients don't re-authenticate constantly, short enough that a lost phone doesn't leave credentials hanging. Use a refresh token if your portal spans days or weeks of client interaction (e.g., an invoice review that takes three days). Keep it simple: access token (short-lived), refresh token (long-lived, rotates on refresh). Implementation: 48 hours with Twilio (fastest path) Let's build this with Twilio because it's fastest to production. You'll need: a backend (Node, Python, Ruby—any framework works), a portal frontend (React, Vue, vanilla JS), and a Twilio account. Step 1: Twilio setup (15 minutes) Sign up at twilio.com. Verify account (credit card required). Buy a phone number (SMS-capable). Cost: $1/month. Choose a region matching your client base. Generate API credentials: Account SID and Auth Token. Store in environment variables. Test a single SMS via Twilio's dashboard to confirm carrier routing. Step 2: Backen