Critical
Core banking, treasury, payment operations, privileged access, administrative consoles and the cardholder data environment.
Minimum: Phishing-resistant factor on every session. No weaker fallback permitted.Stop phishing at the login. Cover every access path.
Crux delivers one adaptive multi-factor authentication platform across every route into your estate — legacy and host systems included — with phishing-resistant factors where value concentrates and silent sign-on where risk is low.
- 01 Request A user, admin or partner reaches any application through any access path
- 02 Signals Device posture, location, behaviour and threat intelligence are evaluated
- 03 Policy The application tier and the risk level select the minimum requirement
- 04 Factor Silent SSO, a prompt, step-up to a stronger factor, or deny
- 05 Evidence A tamper-evident record is written before any credential is released
01 — What we usually find
Strong authentication, applied unevenly
Authentication strength is assessed per access path, not per user. A workforce that uses MFA for email can still have a dozen routes into sensitive systems that ask for nothing but a password — and partial coverage produces both audit findings and open attack paths.
| Common gap | What it leads to |
|---|---|
| No single authentication policy | Control strength varies by application, and the weakest one defines your real exposure |
| Password-only internal applications | A stolen credential goes straight to application access |
| SMS codes as the primary factor | Exposed to SIM swap, interception and real-time relay by phishing proxies |
| Legacy and host systems outside scope | Lateral movement after initial compromise meets no challenge |
| No MFA at Windows and server logon | Endpoint and administrative access carry no second factor |
| No consolidated authentication log | Detection use cases cannot be built and audit evidence cannot be produced |
| No coverage measurement | Nobody can state the organisation's MFA position with confidence |
02 — Why now
What regulators and attackers now require
PCI DSS v4.0.1 requires MFA for all access into the cardholder data environment (8.4.2), for non-console administrative access (8.4.1) and for remote network access (8.4.3). Requirement 8.5.1 goes further: the MFA must resist replay, use at least two different factor types, and must not be bypassable without documented, time-limited authorisation. That last clause is where many existing deployments quietly fail.
SAMA's cyber security framework expects MFA for privileged and remote access and an MFA capability for customer online services — and assesses maturity, not mere possession of a product. NCA's Essential Cybersecurity Controls require MFA for remote and privileged access alongside centralised identity management and complete logging.
The threat side has moved faster than most MFA estates. Adversary-in-the-middle phishing kits relay passwords and one-time codes in real time, and push-fatigue attacks simply prompt until someone taps approve. One-time codes stopped being sufficient protection for high-value access some time ago; the requirement now is phishing-resistant factors wherever value concentrates.
- Data residency — identity, credential and authentication audit data kept inside the Kingdom, with no external dependency on critical login paths
- Operating cost — duplicated MFA licences, repeated enrolment and avoidable password-reset volume, all consolidated onto one platform
- Audit evidence — a per-path control mapping that internal audit and the regulator can actually test
03 — The policy model
Tier 1
Tier 2
Tier 3
Three tiers, and a decision on every authentication
Every application is placed in a tier. The tier sets a minimum; live risk decides what happens above it. Risk is assessed continuously — at every authentication, not only at first sign-on.
Sensitive
ERP and HR, business intelligence, credit and lending, contact centre tooling and similar systems holding sensitive data.
Minimum: MFA at sign-on, plus step-up on privileged actions and elevated risk.General
Intranet, collaboration, service desk and general line-of-business applications.
Minimum: Single sign-on, with risk-based step-up only when signals warrant it.The decision matrix
What the platform does for each combination of tier and assessed risk. Thresholds are tuned during the engagement against real traffic, not fixed in advance.
Low risk
Medium risk
High risk
Threat match
Tier 1Critical
Phishing-resistant factor
Factor plus device check
Factor plus restricted session
Deny and alert the SOC
Tier 2Sensitive
SSO with MFA at sign-on
Step-up
Step-up plus restricted session
Deny and alert the SOC
Tier 3General
SSO, no prompt
MFA prompt
Step-up to a stronger factor
Deny and alert the SOC
Low-risk access to general applications passes silently. That is deliberate: prompt fatigue is a symptom of a flat policy, and a policy that challenges everything trains people to approve anything.
04 — Factor catalogue
The right factor in the right place
The strongest factor is concentrated where value concentrates — not spread thinly across everyone. SMS is demoted to an approved, time-limited fallback and never accepted for Tier 1 or privileged access.
-
FIDO2 / WebAuthn passkeyHighest — phishing resistantPrivileged accounts, treasury and payments, and every Tier 1 system
-
Push with number matchingHighGeneral workforce access to enterprise applications
-
Device-bound biometricHighCustomer internet and mobile banking
-
Smartcard / PKIHighWhere a card estate already exists; shared workstations
-
TOTP and hardware tokensMedium-highContractors, branch floors and users without a smartphone
-
SMS or email codeLow — fallback onlyTime-limited approved fallback; never Tier 1 or privileged
-
Break-glass codeControlledEmergency access on approval — single use and fully audited
05 — Coverage
Eleven integration patterns, one policy
Every application is assigned one pattern at intake. The pattern fixes the runbook, the test set and the change required — which is how applications that cannot be modified still end up covered.
| Application type | Integration pattern | Change required |
|---|---|---|
| Modern web and SaaS applications | SAML 2.0 / OIDC federation with step-up | Configuration only |
| Cloud productivity and identity estate | Federation or external authentication method | Configuration only |
| Remote access, VDI, network devices | RADIUS with challenge-response | Configuration only |
| Windows logon, RDP, servers | Endpoint agent with policy enforcement | Agent deployment |
| Linux and Unix servers, SSH | Pluggable authentication module | Module configuration |
| Legacy web applications | Reverse proxy with authenticated header injection | None |
| Host, mainframe, thick-client apps | Directory-layer enforcement, agentless | None |
| Databases and privileged sessions | Privileged access integration at checkout | None |
| In-house and custom applications | Authentication REST API or SDK | Light integration |
| Customer digital channels | Mobile SDK with risk-based step-up | SDK integration |
| Partner and open banking APIs | Strong customer authentication at the API gateway | Gateway policy only |
06 — Security position
How MFA actually gets beaten, and the design answer
Attackers rarely break the factor. They route around it: through a softer path, a softer person, or a session that outlives its authentication. The design has to close each of those deliberately.
| Attack | Why it works conventionally | Architectural response |
|---|---|---|
| Adversary-in-the-middle phishing | A proxy relays credentials and one-time codes in real time | FIDO2 origin binding on Tier 1 and privileged paths; codes not accepted there |
| Push fatigue | Repeated prompts until the user accepts one | Number matching, contextual prompts, rate limits, repeated-denial detection |
| SIM swap and interception | SMS treated as possession when it is not device-bound | SMS restricted to approved fallback, excluded from Tier 1, reported monthly |
| Helpdesk social engineering | Resetting a factor is softer than defeating it | Identity verification workflow, dual approval for Tier 1, every reset audited |
| Enrolment hijack | An attacker registers a factor before the real user | Enrolment tied to an authoritative event, not self-assertion |
| Legacy protocol bypass | An older authentication path predates the control | Legacy paths discovered and blocked before enforcement |
| Proxy or agent bypass | The application is still reachable directly | Network restriction so protected apps accept traffic only via the proxy |
| Session and token replay | A stolen session outlives its authentication | Short lifetimes, audience restriction, device binding, re-auth on sensitive actions |
| Insider policy weakening | Policy changed from inside with no visibility | Segregation of duties, four-eyes on policy promotion, alerts to the SOC |
07 — AI and authentication
AI made phishing better. It also makes the policy smarter.
Generative AI has removed the spelling mistakes and awkward Arabic that used to give phishing away, and cloned voices now call helpdesks asking for factor resets. The same techniques, applied on the defending side, are what make adaptive authentication work.
Behavioural risk scoring
Each authentication is scored against how that identity normally behaves — time, device, location, velocity. Deviation raises the risk level in the decision matrix; normal behaviour passes quietly.
Adaptive policy · BaselinesImpossible travel and velocity
Logins from two cities an hour apart, or a burst of attempts across many accounts, are weak signals individually and strong ones combined.
Credential stuffing · Account takeoverPrompt-bombing detection
A run of denied push requests is an attack in progress, not a user having a bad morning. Detecting the pattern lets the platform block and alert rather than keep prompting.
Push fatigue · SOC alertingHelpdesk reset fraud
Voice cloning makes caller verification by knowledge questions unreliable. Reset requests are scored for risk and routed to stronger verification before any factor is changed.
Deepfake voice · Reset controlsArabic-language phishing
Lures written in fluent Arabic by language models are now routine. Phishing-resistant factors are the durable answer, because they do not depend on the user spotting the fake.
Arabic lures · Origin bindingTuning, not guessing
Monitor-mode data from each rollout wave trains the thresholds before enforcement, so the policy reflects your real traffic rather than a vendor default.
Monitor-then-enforce · Thresholds
08 — Architecture
The principles the platform is built on
- One policy authority — no in-scope application authenticates users independently; integration methods vary, the policy and audit trail do not
- No application change as the price of coverage — systems that cannot be modified are covered at the directory or proxy layer
- Active-active with a defined degraded mode — no single point of failure; cached endpoint authentication keeps branches working while Tier 1 fails closed
- The directory stays authoritative — no parallel identity store, so joiner-mover-leaver lifecycle stays in one place
- Audit before release — every decision, enrolment, reset, bypass and policy change is recorded tamper-evidently and streamed to your SIEM
- Keys in hardware — cryptographic key material held in an HSM, with no secret stored in reversible form
- Arabic and English throughout — enrolment journeys and prompts with right-to-left layout validated in user acceptance testing
- Exceptions visible, owned and time-bound — any uncovered application is registered with a compensating control and a review date
Availability, failover and latency targets are agreed per engagement against your peak authentication volumes and recovery requirements.
09 — Delivery
Monitor first, enforce second, wave by wave
The fear with MFA rollouts is a Monday morning with thousands of people locked out. The method exists to make that impossible: every wave runs in monitor-only mode first, enrolment completeness is a hard gate, and every step has a rollback.
-
Week 1
Mobilise and baseline
Application inventory baselined and tiered, design confirmed, infrastructure verified. The enrolment campaign starts immediately and runs ahead of every enforcement date.
-
Week 2
Platform build
High-availability install across sites, directory integration, certificates and key store, SIEM feed. Platform operational in production.
-
Week 3
Pilot and onboarding factory
IT pilot group enrolled and validated, delegated administration and break-glass signed off, and the repeatable onboarding process live.
-
Weeks 4–5
Wave A — highest risk
Remote access, VDI, privileged access and admin consoles, integrated in monitor mode, then enforced once the monitor report is accepted.
-
Weeks 5–6
Wave B — enterprise apps
Federated and reverse-proxied applications, monitored then enforced. Directory-layer enforcement staged by group.
-
Weeks 6–7
Wave C — host and legacy
Host applications enforced, exception register closed, disaster-recovery drill run and penetration test supported.
-
Week 8
Stabilise and hand over
Hypercare, defect closure, evidence pack, runbooks and knowledge transfer, and decommissioning of legacy point solutions.
What an eight-week core programme depends on: infrastructure ready before week one, an application inventory that exists or can be produced immediately, policy decisions taken before mobilisation, a standing directory change window, and security keys procured early. Where those are not in place, the start date moves — the gates do not. Customer channels and long-tail applications typically follow as parallel tracks.
10 — Questions
Answered plainly
Why is SMS not good enough as a second factor?
SMS codes can be intercepted, redirected by SIM swap, or relayed by a phishing proxy in real time — as can any one-time code the user types. SMS remains acceptable as a time-limited fallback, but not as the primary factor for privileged or critical access.
What makes a factor phishing-resistant?
Origin binding. A FIDO2 security key or passkey cryptographically checks that it is talking to the genuine site, so a look-alike domain or relay proxy receives nothing it can reuse. One-time passwords and plain push approvals lack that binding, which is why adversary-in-the-middle kits defeat them.
Can MFA cover legacy and host applications that cannot be changed?
Usually yes. They are covered at the directory layer, through a reverse proxy that injects authenticated headers, or through privileged access checkout. The integration method varies by application; the policy and the audit trail do not.
What does PCI DSS v4.0.1 require for MFA?
MFA for all access into the cardholder data environment (8.4.2), for non-console administrative access (8.4.1) and for remote network access (8.4.3). Requirement 8.5.1 adds that the system must resist replay, must not be bypassable without documented and time-limited authorisation, and must use at least two different factor types.
Will adaptive MFA annoy users with constant prompts?
Done properly, it reduces them. Low-risk access to general applications passes silently through single sign-on; the platform steps up only when the application is sensitive or the signals raise the risk. Prompt fatigue comes from flat policies, not from MFA.
How do you avoid locking users out on cutover day?
Monitor before enforcing. Each wave runs in monitor-only mode for several working days, reporting who would have been challenged or blocked. Enrolment completeness is a hard gate, audited break-glass access exists before enforcement, and every step has a rollback.
Can authentication data stay inside Saudi Arabia?
Yes. The platform can be deployed on-premises across your own data centres, keeping identity, credential and audit data in the Kingdom with no external dependency on the login path. Where cloud is acceptable, residency is assessed against your sector regulator's requirements.
Regulatory references summarise requirements in general terms. Confirm applicability to your organisation against current PCI SSC, SAMA and NCA publications.
Start here
Find out how many of your access paths ask for nothing but a password
A coverage assessment maps every access path into your estate, tiers each application, and reports where MFA is enforced, where it is bypassable and where it is missing — the position most organisations cannot currently state.