When Security Controls Make Customers Less Secure
For five years, I travelled throughout Central and South America while continuing to manage my Canadian bank accounts.
You would think that logging into online banking would be an easy part of the digital nomad lifestyle.
It wasn’t.
One bank required an SMS verification code every time I signed in from a new location, added an e-transfer recipient, or changed certain account information.
A sensible security control, until you leave Canada (or North America, if you don’t get hit with insane roaming charges).
My Canadian phone number couldn’t reliably receive those messages where I was travelling. Nor could I change the account to an international number because the bank wouldn’t send verification codes internationally. And without the code, I couldn’t complete the transaction.
Frustrating because other international businesses like ActiveCampaign, Google and and Zoom let me switch to my Nicaraguan number…
Now, SMS verification codes as the security control were technically functioning exactly as designed.
I simply couldn’t access my own money.
A few months before I returned to Canada, another bank went one step further: its geolocation controls blocked me from logging in from parts of Central or South America at all.
As a cybersecurity professional, I understand the theory. I’ve helped designed these types of controls for many corporate systems.
We’re all warned about the cyber threats out there.
A login attempt from another country can indicate account takeover. Location can be a useful risk signal. But “this customer is outside Canada” and “this is a criminal attempting to access the customer’s account” are not the same conclusion.
That distinction is really critical when setting up your company security controls.
Because when legitimate customers repeatedly hit security controls that make it impossible to do what they need to do, they don’t necessarily stop…or come home.
They improvise.
They change the phone number on the account to a relative’s number. They ask a friend at home to log in for them. They share a password so someone else can add the new e-transfer recipient. They leave a session signed in longer than they otherwise would. They search online for a workaround that may introduce entirely new risks.
In other words, the system intended to prevent unauthorized access can pressure customers into breaking Security Awareness Rule Number One:
Never share your password with anyone.
That isn’t a “user problem.”
It’s an architecture problem.
Security controls don’t operate in a laboratory
Cybersecurity decisions are often made around an expected user, in an expected location, using an expected device, on an expected network.
In North America, that expected user is frequently assumed to have:
A North American mobile number
Reliable cellular service
Continuous access to that number
A familiar device
A familiar IP address
A relatively predictable login location
That may describe a large portion of customers.
It does not describe all legitimate customers.
People travel. Business owners work internationally. Employees relocate. Digital nomads run North American companies from other countries. People replace phones, change carriers, lose access to old numbers, cross borders and connect through unfamiliar networks.
And when we travel, that is when we’re most likely to get a phone swiped or lost while bouncing down a dirt trail to see the most beautiful beach.
These aren’t obscure edge cases anymore. They are normal business use cases (that are still overlooked).
Yet many authentication and fraud-prevention controls still behave as though crossing a border automatically makes someone suspicious, and having access to a domestic mobile number automatically makes someone trustworthy.
Neither assumption is very reliable, when you truly think about it...
SMS authentication is not the gold standard we sometimes treat it as
To be clear, SMS-based multifactor authentication can provide more protection than relying on a password alone.
But that doesn’t make it the strongest option, or an appropriate option as the only available authentication method.
SMS codes can be exposed through SIM-swapping and port-out fraud, social engineering, phishing and compromised telecommunications accounts. The FCC has specifically introduced rules intended to protect consumers from SIM-swapping and port-out fraud because of the account-takeover risks these attacks create.
CISA recommends phishing-resistant multifactor authentication and notes that SMS authentication is not phishing-resistant. NIST’s digital identity guidance also treats authentication through the public telephone network as carrying additional risk and calls for organizations to evaluate that risk and provide meaningful alternatives.
That last part is important:
Provide meaningful alternatives.
During my travels, the bank that gave me the best experience was TD Canada Trust. At the time, I could use an authentication application that generated a new temporary code at regular intervals.
Not only did I not need a Canadian cellular connection, but I wasn’t handcuffed to a particular SIM.
(I watched a friend scramble to regain access to his accounts after his phone was stolen. He was caught in an endless loop of being asked to check for the SMS code in order to cancel his credit cards and set up any fraud detection on his bank accounts (as the cards were stolen too). This situation is largely neglected in most client-side security controls who rely on SMS verification codes to operate.)
An authentication app was more reliable, usable and better aligned with the risks.
That is what good security architecture should accomplish.
Friction is not proof that a control is effective
Security and inconvenience are often treated as though they naturally belong together.
If a control creates friction, it must be doing something important, right?
Not necessarily.
Some friction is justified. Adding a new payee, changing contact information or initiating an unusual transfer may warrant additional verification. That’s fair, in my opinion.
But effective security applies friction deliberately and proportionately.
It asks questions such as:
What specific threat are we trying to reduce?
How likely is that threat in this particular environment?
What legitimate customer scenarios could trigger this control?
Does the customer have another secure way to authenticate?
What happens when the control fails?
Will customers understand what to do next?
Does the recovery process introduce greater risk than the original transaction?
What workarounds are customers likely to create?
Are we evaluating several risk signals, or blocking access because of one?
A customer logging in from another country they don’t typically visit may deserve additional scrutiny.
But geography could be evaluated alongside device history, previous login behaviour, transaction value, account changes, impossible-travel indicators and stronger authentication factors.
A risk signal should inform a decision. It should not automatically become the decision.
The human workaround belongs in your threat model
NIST describes human-centred cybersecurity as an approach that considers how people understand and interact with security systems, processes and services.
That isn’t about making security prettier or removing every minor inconvenience.
It means recognizing that human behaviour is part of the system.
If customers routinely bypass a control, the answer cannot always be another reminder that they should follow the rules. We need to understand why the secure path isn’t serving the legitimate task they are trying to complete.
And, honestly, we need to listen to our customers when they speak up about these security control inconveniences.
A security control can look excellent in a policy document and still fail in production because:
The business requirements were incomplete
Customer use cases weren’t represented
Authentication and recovery were designed separately
Controls were inherited from a template without assessing the actual risk
The technology was selected before the workflow was understood
Security, operations and customer experience teams weren’t communicating
That is why cybersecurity cannot be bolted onto a finished application or network design as a final compliance exercise. And why my approach to cybersecurity involves deep analysis and application of security frameworks that marry the needs of both the business and the customer operations.
Cybersecurity needs someone who can translate between the business, the technology, the customer and the risk, considering behavior analytics and human psychology parameters.
Secure systems must work in the real world
The goal of cybersecurity is not to create the largest possible collection of controls.
It is to choose and architect the right controls for the organization’s risks, systems, customers and budget.
For a small or medium-sized business, that could mean reviewing:
How customers and employees authenticate
Whether account recovery undermines MFA
How applications exchange and protect information
Where sensitive data is stored
How networks and cloud services are segmented
Whether access reflects actual job responsibilities
How new technology will affect the organization’s attack surface
Whether the proposed controls are proportionate to the risk
What customers or employees will do when the intended process fails
This is the space where I do some of my best work.
I assess existing applications, networks and system architecture to identify security risks, control gaps and operational realities. I also review proposed designs and technology initiatives before they are implemented - when the business still has the opportunity to make strategic, cost-effective decisions instead of paying to retrofit security later.
Because the strongest control is not necessarily the most restrictive one.
It is the one that meaningfully reduces risk, supports legitimate business activity and continues to work when a real human uses the system somewhere outside the conditions imagined in the design meeting.
If your customers have to weaken their own security to use your system, the control isn’t working.
It is simply moving the risk somewhere you can no longer see it.
