We are not trying to know everything about a customer
We are trying to reach enough confidence to authorise an action without opening the door to fraud. A senior Ariovis IAM architect walks through two very concrete situations: a consumer who has lost their phone, and a business customer asking for thirty-day payment terms at the counter of a construction-materials store.
Two situations, one question
We regularly design Customer Identity and Access Management journeys for organisations that serve consumers, business customers, citizens, partners, suppliers, members and external collaborators. The underlying technologies often look similar to those used for employees, but the stakes are different. The customer has choice, they have no time, and the first purpose of authentication is almost never internal compliance. It is fraud prevention.
The useful question is therefore not always: can we fully prove who this person is? It is often: do we have enough reasons to believe that this person is the legitimate account holder and that the requested action can be accepted? These are not the same conversation.
Two situations come up constantly in our discussions with fraud leads, digital owners and security architects. A consumer who has lost their phone and reinstalls an app. A business customer who walks into a construction-materials store and asks to pay in thirty days, once their own client has paid them. On the surface these situations feel unrelated. In practice they raise the same question: how much confidence do we need before we accept the request?
Identity is not a piece of information we try to accumulate. It is a level of trust we build in order to make a decision.
The lost phone: rebuilding a session without turning an incident into an ordeal
The first case is unremarkable, which is precisely why it deserves care. A customer regularly uses a retailer's mobile app. Their old phone is lost, broken or stolen. They get a new one, install the app, remember their username and password. The journey could then ask for the password, an SMS code, an ID document, a series of personal questions and a call to customer support. Each additional step looks like added security. It can just as easily turn an ordinary incident into a punishing experience.
The password the customer enters is the Explicit Authentication step of the journey: the service checks something the customer knows and provides on purpose. We do not treat that as absolute proof. Passwords get compromised, reused across services, phished, or stored in loosely protected places. They still count as a first element of trust. The decision does not have to stop there.
Before pushing the customer into a new action, the journey can look at context — what we call Implicit Signals. Depending on the device, the operating system, the app and the components in place, these signals can cover geography, IP address, network, device language and timezone, device model, OS version, device integrity, presence of root or jailbreak, use of an emulator, IP reputation, attempt velocity, historical connection patterns for the account, and behavioural signals observed during input. Some projects reach for more intrusive signals such as contact lists or installed-app categories; these are highly sensitive, largely restricted by mobile platforms and by applicable law, and we do not build our detection on them. A good risk signal is not just technically available. It also has to be legitimate to collect and genuinely useful to the decision.
These signals are not proofs in isolation. A new device is not automatically fraud. A new IP is not automatically suspicious. A different language is not evidence of compromise. Travel is not a crime. A Risk-Based Authentication engine combines the signals into a Risk Score that the business interprets. In our case the device is new, but the connection comes from the usual area, language and timezone are consistent, no root is detected, the typing behaviour matches previous sessions, and there is no abnormal recent activity. The score stays low. The customer can be signed back in without being pushed through an additional explicit factor.
We are careful, at this exact moment, not to indulge in a common abuse of language. What we just did is not necessarily multi-factor authentication. The password is still the explicit factor. The contextual signals raise the Authentication Assurance of the attempt; we would rather call this Adaptive Authentication. It is not automatically MFA. It is authentication whose level of confidence is enriched by context.
When to raise the bar, and what a real step-up looks like
The same journey has to produce a different outcome when signals tell a different story. This is where Step-Up Authentication comes in. We ask for the missing confidence to be provided — not by demanding more information from the customer, but by asking for stronger proof. Here are the situations we walk through with fraud and product teams.
- 01
An unknown device from an unusual country
The password is right, but the device is new, the location does not match any prior session, the app immediately asks for sensitive data and the typing pattern is far from the usual one. The Risk Score climbs. We trigger a more demanding step-up: a passkey if the customer has enrolled one, a validation over another already-trusted channel, a previously enrolled strong factor, or Identity Proofing for the most sensitive cases. What triggers friction is not the newness of the device on its own. It is the fact that several signals stop lining up with any previous behaviour.
- 02
A compromised device or an emulator
Device Posture reveals a rooted phone, a jailbreak, an emulator, a very old OS or an altered app binary. Even with a correct password, that is not neutral. We refuse a silent re-authentication and require step-up, sometimes a framed Account Recovery flow, and for sensitive actions a human intervention from support. The Device Trust a vendor talks about is not just a device identifier; it depends on what the device is willing to say about itself and on our ability to verify that story.
- 03
An immediate request for a sensitive change
The customer has just signed in and asks, in the same session, to change their shipping address, their bank account or their authentication factor. The expected level of proof is no longer the same as for browsing an order history. We apply an explicit business policy: some actions force a step-up even when the overall score is low, because their fraud potential is asymmetric. The score helps make a decision; it does not replace one.
- 04
SMS is not the default answer
SMS is often the first reflex of a project team because it is easy to deploy. That does not make it a strong factor. The French cybersecurity agency (ANSSI) explicitly recommends against using SMS as the channel for receiving an authentication factor, given interception risks, SIM swapping, number reallocation and the structural weakness of the channel. We do not claim SMS is worthless — it can support detection or serve as a fallback where nothing else exists — but we do not present it to the customer as a strong guarantee. Passkeys, a previously enrolled authenticator app or a validation on an independent channel the customer already uses are usually stronger choices.
- 05
Three marketing formulations we always challenge
Three phrases show up in vendor demos. "We do invisible MFA" — no, a risk analysis can raise confidence significantly without being, strictly speaking, an independent second factor. The point is not to relabel a Risk Score as MFA; it is to make a decision that matches the confidence actually available. "We recognise the device" — recognised how? A cookie, an app identifier, a cryptographic key, an attachment to an Apple or Google account? Can it be copied, does it survive a reinstall, is it revoked when the phone is lost? Recognising a device is not yet recognising the person holding it. "The risk score decides" — no, the engine computes a risk; the business decides what it accepts to do with that risk. A score of 70 has no universal meaning.
- 06
What we always ask an Adaptive Authentication engine
Which signals are used and why. How they are weighted. Which rules trigger a step-up. How false positives are tracked and corrected. How a legitimate customer recovers when the decision turns against them. How the decision is explained after a proven fraud case. How the rules evolve as incidents accumulate. An engine that refuses to answer these questions is not ready to sit inside a serious CIAM journey. The score supports a decision. It does not replace policy.
- 07
Account Recovery as a first-class journey
A large share of fraud concentrates on recovery flows. We treat them as full journeys, with explicit rules, graduated proofs, a decision log and a clear articulation with support. A recovery flow is not a back door around Risk-Based Authentication; it is a flow that has to be at least as rigorous as a normal sign-in, often more.
When risk goes up, we do not ask for more information. We ask for stronger proof.
The trade counter: telling apart the company, the person and the mandate
The second situation feels far from the first, but reveals the same structure. A business customer walks into a construction-materials store. Their company is a regular customer, past orders have been paid on time. They present a company registration extract (in France, a Kbis) and ask for thirty-day payment terms, once their own client has paid them. For the store, this has real commercial value: it retains the professional and eases their cash flow. The main risk is not necessarily the company's solvency. The account is known, the history is clean. The question becomes: is the person at the counter authorised to bind this company to this operation? Here is how we work that journey through with the team.
- What a company registration extract does and does not prove
- A Kbis or its equivalent evidences the existence and some attributes of the company: name, registration number, address, legal representatives, administrative details. It does not always establish that the person holding it is who they claim to be, that they still work for the company, that they are allowed to place orders, that they can negotiate payment terms, or that they can bind the company up to the amount being requested. We therefore separate three questions: does the company exist, who is the person at the counter, and is this person allowed to bind this company for this operation? Knowing the company, recognising the person and verifying the mandate are three different decisions.
- Leaning on an already-verified identity
- Rather than ask the customer to fill in a complex file or produce several documents that are hard to check at a counter, the store can lean on an external Identity Provider. Depending on context, service eligibility and available agreements, this can rest on a full flow run through Ping Identity, on b.connect for an authentication grounded in an existing banking relationship where partner services allow it, on FranceConnect or FranceConnect+ where the service is eligible, on a recognised digital identity or on another provider fit for the market and the required Authentication Assurance level. These providers are not universal replacements for the store's own CIAM; their use depends on the audience, the level of proof, the available attributes, the contractual framework and user acceptance.
- The actual counter journey
- The salesperson finds the company's account and sees that it is a client, that the history is clean, that the requested amount is consistent, that no specific incident is on file. The person scans a QR code or uses the intended channel. They authenticate through an accepted Identity Provider. The store receives what it needs to link the person to the corporate account. The system then checks whether they are already known against that account, or match a registered representative, or whether the operation must be validated by a company officer, or whether a first Delegated Authority has to be captured. The salesperson does not have to become an expert in forged documents; the customer does not have to build a disproportionate file.
- The employee who is not a legal representative
- In construction, purchases are rarely made by the executive: they are made by a site manager, a foreman, a buyer, an authorised employee or a subcontractor acting on behalf of the company. That person can be perfectly legitimate without appearing on the registration extract. The system has to model the delegation: an executive or a registered manager enrols an authorised employee, the company confirms the request, the delegation is time-bound, has a cap, is restricted to certain stores or product families, and large operations require a further validation. Identity tells us who is acting. Delegated Authority tells us on whose behalf and up to which limit.
- The identity provider helps, it does not decide
- The Identity Provider brings proof about the person's identity or authentication. It does not decide, on the store's behalf, whether to grant the payment terms. The store combines that proof with the corporate account, its history, the amount, the list of known buyers, existing delegations, past payment incidents and its own commercial policy. Federating an identity does not mean outsourcing the customer relationship. It means borrowing trust that has already been built, when that trust matches the need.
- How a Corporate Account differs from a consumer account
- The account we attach the person to is not a consumer account in the strict sense: it is a Corporate Account with its own attributes — order history, outstanding balance, ceilings, incidents, list of authorised buyers, stores visited. The attachment of a person to that account has to be explicit, reviewable and revocable. A person can be added, removed, restricted to certain stores, amounts or operation types. The Business Identity of the store is not just a sum of consumer accounts; it is an object with its own governance, and it has to be designed as such.
- Where Ping Identity sits in our practice
- Ping Identity is our reference technology partner for Access Management and CIAM. Depending on the components involved, Ping can help orchestrate authentication flows, federate external Identity Providers, manage sessions, apply Adaptive Authentication, collect and evaluate risk signals, establish Device Trust, trigger a step-up and secure recovery flows. We never present these capabilities as automatically bundled inside a single module or automatically available in every project: they are assembled to fit the target architecture. Where the existing landscape or project calls for it, we also work on Microsoft Entra ID or Keycloak-based architectures.
The fraud angle, and the privacy angle
We do not deploy Adaptive Authentication, a Risk Score, identity federation, Identity Proofing or delegation management to collect more data. We deploy them to prevent concrete Fraud Prevention cases. In the first situation: account takeover after a lost phone, recovery-flow abuse, use of a compromised password. In the second: professional impersonation, fraudulent use of a company's account, credit requested by an unauthorised person, orders placed in the name of a real company by a third party. The control has to be proportionate to the potential loss and to the trust we already hold.
The more Behavioral Signals and device signals we collect, the richer the analysis. It also grows the volume of data processed, the sensitivity of the profile built, the disclosure obligations, the impact of a breach, the risk of an opaque decision and the burden linked to consent and retention. More signals do not automatically mean more security. Each signal has to answer four questions: does it actually change fraud detection, is it legitimate to collect, how long should it be kept, and could the same decision be made with less intrusive information? Fraud does not justify observing everything. It justifies choosing the signals that actually move the decision.
We routinely meet organisations that push SMS on every user because it is easy, that treat every new device as fraud, that let an opaque score block a loyal customer, that require an ID document for actions with no real stake, that treat a company registration extract as proof of the bearer's identity, that conflate the executive's identity with employee delegation, that trust an Identity Provider without checking the level of proof it actually returns, or that collect many signals without knowing which ones influence the decision. These are not bad intentions: they are the consequences of a journey designed without asking which fraud it is meant to prevent.
Trust is cumulative. No single element is enough on its own. In the phone case, a correct password, a consistent device, a familiar location, no abnormal behaviour and a low-sensitivity action can together add up to enough confidence. In the counter case, an existing company, a clean account, an authenticated person, a known relationship with the account, a consistent amount and no incident on file form a set. We are not looking for perfect proof. We are looking for a combination of proofs coherent enough for the action we are being asked to accept.
What we ask before designing a journey
The customer who had lost their phone did not go through a disproportionate journey. Their password, their context and the low risk associated with the attempt were enough to restore the session. A step-up remained available if the signals had told a different story. The professional at the counter did not obtain payment terms simply because they held a company registration extract: the store combined the existence of the company, its commercial history, the person's identity, their relationship with the corporate account and their authority to commit to this operation.
In both cases, the organisation was not trying to know everything. It was trying to know enough to accept the request without unnecessary exposure — for the customer, for the company and for itself. When we design a CIAM journey, we do not start by asking how to identify the customer more thoroughly. We start by asking which fraud we are trying to prevent, how much trust we already hold, and what missing proof would actually let us accept the action.