Root of Trust: Fix the Business Process Before You Bypass the Security
When a business process hits a security control that is not yet in place, such as an inactive banking app, you should fix the journey rather than bypass the control. Establish identity, create the profile, securely enrol the device and confirm the trusted channel works before asking for sensitive approval.
Picture a business process that reaches the point where a customer must approve something important, where the intended control is an approval through their banking app, but the app has not yet been activated. Someone suggests sending an SMS instead so that the process can continue, and in the moment this sounds like a perfectly practical answer to a blocked customer. What it actually reveals is that the business process has arrived at a security dependency before satisfying it, because if the app is the designated trusted channel, then the process must establish that channel before it asks the customer to use it.
Once you design a root of trust, your business processes have to respect it. When a journey cannot work within that design, it is the journey that needs fixing, since the alternative is a business that gradually accumulates exceptions which quietly undo the protection it invested so heavily in building.
1. What Is a Root of Trust?
Every security system needs a starting point it can rely on. In technical architecture, a root of trust is the foundational component or capability on which other security decisions depend, often supported by protected hardware and cryptographic keys, and it provides the basis from which trust is extended further up the system.
The same principle applies to a customer journey, where the question becomes what established evidence allows us to trust this person, this device and this instruction. For a banking app, that evidence should include how the customer’s identity was verified, how their device was enrolled and how its credentials are protected, because every subsequent approval depends on the integrity of that relationship.
Calling the app the root of trust is useful business shorthand, but installing an app does not establish trust on its own. The real foundation is the verified relationship between the customer, the enrolled device and the bank, supported by the underlying security controls; an attacker can install exactly the same app, but they must not be able to establish the same authority.
Think of a building with a carefully controlled entrance, where people receive verified access badges before they go any further. If someone arrives at a restricted room without a badge, the correct response is to establish their entitlement through the approved process, and letting them in because they happen to know an employee’s name simply defeats the purpose of controlling the entrance in the first place.
2. A Sequencing Problem Must Be Fixed in the Sequence
Consider a generic lending journey in which a new customer needs to approve a sensitive instruction. The process expects that approval to come through the app, but the customer’s digital profile and device enrolment are incomplete, which leaves the team handling the application facing a blocked customer and considerable pressure to finish.
The obvious workaround is to use a channel the customer already has, such as SMS. However, if the action genuinely requires the assurance provided by an enrolled app, an SMS does not automatically provide an equivalent basis for trust, and the missing prerequisite remains missing even when the workflow now shows a reassuring green tick.
The process should establish identity, create the necessary customer profile, securely enrol the device and confirm that the trusted channel works before it ever presents the sensitive approval. Those dependencies belong in the design of the journey itself, so that neither customers nor frontline employees have to discover them at the point of failure.
There is an essential qualification here, which is that activation itself must be secure. A newly installed app cannot establish its own legitimacy merely by approving a prompt inside itself, so initial enrolment needs an independent and appropriately strong basis for binding that device to the verified customer.
Moving a weak verification step into an app does not make it strong, because the entire chain matters, beginning with how trust is first established. A beautifully protected approval is of very little value if a criminal could have enrolled the approving device.
3. The Fallback Becomes Part of the Security Model
Security designs often describe the preferred path in impressive detail: the customer uses a recognised device, proves possession of a protected credential and approves an instruction through an authenticated channel. Then, almost as an afterthought, a small paragraph explains that if this fails, someone can use another method.
That small paragraph deserves exactly as much scrutiny as the main design. If an attacker can deliberately trigger the fallback, then its controls become directly relevant to the security of the protected action, and a route described internally as an exceptional convenience may well become the attacker’s preferred way in.
SMS illustrates the issue neatly. NIST SP 800-63B classifies authentication over the public switched telephone network as a restricted authenticator, and manually entered one time codes do not qualify as phishing resistant, since they can be captured and relayed by an attacker while telephone number takeover introduces further risks of its own.
None of this means that every SMS is dangerous or that messages have no useful role, because an informational notification serves a very different purpose from evidence that authorises a sensitive change. The important question is whether the business has quietly promoted a convenient communication channel into a substitute for stronger proof.
4. Cybercrime and Scams Exploit Uncertainty
Criminals benefit whenever customers cannot reliably distinguish a legitimate business process from an invented one. If genuine journeys sometimes require an app, sometimes a code, sometimes a link and sometimes an urgent conversation with an employee, then an impersonator has plenty of plausible instructions to choose from, and every inconsistency hands the criminal another story that might sound reasonable.
AI adds to that challenge by making convincing impersonation easier and cheaper to produce. The FBI has warned that criminals are using generative AI to produce text, fake documents, cloned voices and synthetic video in support of financial fraud, which means familiar language, a recognisable voice or a professional appearance cannot carry the weight of identity verification on their own.
A consistent trusted channel gives customers a clear place to verify what is actually happening. They should be able to open the app independently and inspect the real request without trusting a link or a caller’s explanation, and the approval itself should describe the action clearly enough for the customer to understand its consequences.
Even then, authentication alone does not eliminate scams, because a criminal may persuade the genuine customer to approve a harmful payment through their genuine app. Transaction checks, meaningful warnings, appropriate limits and timely intervention all remain necessary, since proving who approved an action does not prove that they understood it or that they were free from manipulation when they did so.
5. Recovery Must Restore Trust
Phones break, devices are stolen and customers lose access, and a security design that ignores these ordinary events will inevitably create pressure for improvised exceptions. Recovery therefore belongs in the original architecture and in the original customer experience rather than being bolted on later.
The objective of recovery is to reestablish trust through a controlled process that is appropriate to the risk. Depending on the circumstances, that might involve another previously enrolled authenticator, renewed identity verification or an assisted process with independent checks, and sensitive activity may reasonably need restrictions while that recovery is completed.
Customers who cannot use the primary channel also need a deliberately designed alternative, one that provides suitable assurance for the actions it permits along with clear limits and accountability. Accessibility and inclusion deserve a proper design of their own rather than an informal exemption that nobody really owns.
The same discipline applies to employees, since a member of staff should not be able to remove a critical protection simply because a caller is convincing or a transaction feels urgent. Where manual intervention is genuinely necessary, its authority, the evidence it relies on and its limits must all be explicit.
6. Business Leaders Own the Process
These problems are often labelled security issues and handed to technology teams, yet the root cause may sit in product onboarding, the order of operational steps, incomplete customer records or a performance target that rewards completion regardless of how it was achieved. Fixing them requires the owners of those processes to act.
A useful review starts with every action that can move money, disclose sensitive information or transfer control of an account. For each one, ask what evidence authorises it, how that evidence was established and what happens when it is unavailable, and then examine every alternative route, including support calls, branch procedures, recovery flows and administrative overrides.
The controls also need to be enforced by the systems that execute the action, because a rule written in a procedure is fragile if an alternative screen or service can simply bypass it. The backend should verify the required authority and approval itself, rather than assuming that some earlier part of the journey must already have done so.
Repeated requests for exceptions are valuable evidence in their own right, since they indicate that a journey is missing a prerequisite, an alternative route or a workable recovery mechanism. Leaders should treat that evidence as a signal to repair the process and to make the secure path the straightforward one for customers and staff alike.
A root of trust only protects the business when the business consistently honours it. If the trusted app must be ready before an approval, make it ready earlier through secure enrolment, and whenever the process conflicts with the trust model, fix the process before the exception quietly becomes the way in.