Bank Negara Malaysia raises authentication rules for financial institutions

At a glance

What this is: This is an analysis of Bank Negara Malaysia’s updated RMiT policy and the authentication, device-binding, and fraud-prevention controls it strengthens for regulated financial institutions.

Why it matters: It matters because IAM, PAM, and customer authentication teams now need controls that go beyond SMS OTP and align identity assurance to device state, transaction context, and change verification.

By the numbers:

• In 2024, Malaysian banks collectively blocked over RM 399 million in fraudulent transactions, five times the amount actually lost to online fraud that year.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read Authsignal’s analysis of Bank Negara Malaysia’s updated RMiT authentication requirements

Context

Bank Negara Malaysia’s updated Risk Management in Technology policy tightens authentication expectations for regulated financial institutions, especially around device binding, phone-number changes, cooling-off periods, and MFA. The key issue is not whether organisations already have authentication in place, but whether those controls still assume a user, device, and transaction model that attackers have already learned to bypass.

For IAM and fraud teams, the policy reflects a wider shift away from channel-based trust and toward transaction-bound assurance. That shift is directly relevant to human identity programmes, but it also carries lessons for NHI governance: the control problem is not simply proving identity at login, it is maintaining assurance across state changes, exceptions, and high-risk actions.

This is a typical regulatory tightening response, but it maps to a broader industry pattern. As soon as authentication becomes a fraud control rather than just an access control, organisations have to design for binding, step-up verification, and contextual limits as first-class identity requirements.

Key questions

Q: How should financial institutions reduce account takeover risk without relying on SMS OTP?

A: They should move to phishing-resistant authentication, device-bound credentials, and transaction binding for high-risk actions. SMS OTP can still be intercepted or redirected, so it should not be the primary proof of user control for sensitive banking events. The safer model verifies the device, the transaction, and the change request separately.

Q: Why do device changes create more risk than login events?

A: Device changes often transfer trust from one endpoint to another, which is exactly where attackers hide. If the change is approved through the same channel being modified, the attacker can self-authorise persistence. That is why enrolment, replacement, and unbinding need stronger verification than ordinary sign-in.

Q: What breaks when authentication codes are not tied to the transaction?

A: A generic code can be replayed, redirected, or used to authorise a different beneficiary or amount after the user has already approved the session. Transaction binding prevents that by making the approval valid only for the exact payment details shown to the customer.

Q: Who is accountable when fraud-resistant authentication is not implemented?

A: Accountability sits with the institution’s security, identity, and fraud governance functions together, because the control spans customer authentication, transaction monitoring, and device lifecycle management. In regulated banking environments, policy obligations typically land on the firm, not just the product team or fraud team alone.

Technical breakdown

Why SMS OTP fails as an assurance layer

SMS OTP is weak not because it is inconvenient, but because it depends on a delivery channel attackers can intercept, reroute, or suppress. SIM-swap fraud, message deletion malware, and session manipulation all break the assumption that possession of a phone number proves the legitimate user is in control. Once that assumption fails, OTP becomes a transport mechanism, not an assurance mechanism. Modern authentication has to bind the verifier to the transaction, not just the login event.

Practical implication: treat SMS OTP as legacy risk, not a sufficient control for high-value banking actions.

Device binding, unbinding, and change verification

A one-device-per-user model reduces the attack surface by limiting how many endpoints can authorise transactions by default. The harder problem is the lifecycle around binding and unbinding, because attackers often enter through a device-registration change rather than a login event. If number changes or device swaps can be approved using the same channel being changed, the control collapses into self-approval. Robust verification must therefore sit outside the compromised channel and be auditable.

Practical implication: design device enrolment and device replacement as separate privileged workflows with stronger verification.

Cooling-off periods and transaction binding as fraud controls

Cooling-off periods work because newly enrolled devices and freshly changed credentials should not immediately inherit full transaction trust. That delay creates a detection window for velocity checks, behavioural profiling, and exception handling. Transaction binding adds another layer by forcing the authentication code to match the confirmed beneficiary and amount, which blocks post-authentication manipulation. Together, these controls convert authentication from a static gate into a time-bound, context-aware risk process.

Practical implication: enforce staged trust elevation for new devices and bind approval to the exact transaction details.

Threat narrative

Attacker objective: The attacker’s objective is to convert stolen access to a phone number or device into transaction approval and account takeover.

1. Entry begins when an attacker gains control of a victim’s phone number through SIM-swap or similar interception, then uses that access to receive authentication codes. Escalation occurs when the attacker changes the registered device or contact details and preserves access through the same compromised channel. Impact follows when the attacker authorises transfers or account changes that appear legitimate to the institution’s control stack.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Channel-bound authentication is no longer a sufficient trust model for banking access. The update shows that a phone number or SMS path can no longer be treated as a stable identity anchor. That matters because fraudsters do not need to defeat every control when the institution still accepts the compromised channel as the proof of legitimacy. Practitioners should read this as a signal to redesign assurance around transaction context, not just factor possession.

Device binding is really a lifecycle governance problem, not just an authentication feature. The policy’s emphasis on one device per user, controlled exceptions, and auditable changes shows that enrolment, replacement, and removal are the real control surface. This is where identity programmes often fail: the happy path is secure, but the off-path change flow is weak. The implication is that device lifecycle governance now belongs in IAM and fraud operations together.

Transaction binding is the right response to approval-channel abuse. When a code is tied to a confirmed beneficiary and amount, the institution stops relying on a generic approval event and starts verifying intent. That narrows the room for redirection attacks, but only if the binding is enforced consistently across high-risk payment flows. Teams should treat this as a design requirement for step-up authentication, not a cosmetic enhancement.

Bank Negara Malaysia is effectively codifying a broader shift toward phishing-resistant and context-aware identity assurance. The architecture it requires aligns with where many regulators are heading, including device-bound authentication and stronger verification for sensitive changes. For practitioners, that means authentication roadmaps should be measured against fraud resilience, not just user experience or login success rates. The compliance bar is now operational, not theoretical.

From our research:

• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Attackers attempt access to publicly exposed AWS credentials within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• For adjacent secret-risk context, the State of Secrets in AppSec shows that the average estimated time to remediate a leaked secret is 27 days, which is long enough for credential abuse to outpace most manual response cycles.

What this signals

With attackers able to weaponise authentication-channel weaknesses quickly, the practical programme response is to treat customer identity assurance as a fraud-control architecture, not a single MFA choice. The boundary between IAM and fraud operations is shrinking, especially where device state and transaction context determine whether an action is legitimate.

Channel trust debt: institutions that still rely on a stable phone number or a reusable OTP are carrying hidden assurance debt. Over time, this debt shows up as a growing gap between what the policy says should be secure and what the authentication journey can actually prove under attack.

For teams modernising authentication, the right benchmark is whether controls remain valid after channel compromise, device replacement, and transaction mutation. If they do not, then the issue is not factor strength alone, it is whether the governance model can survive a hostile state change.

For practitioners

• Separate device enrolment from routine authentication Require distinct verification for first-time device binding, device replacement, and device unbinding. Make the change workflow auditable and deny inherited trust from the prior device by default.
• Move phone-number changes off the compromised channel Do not approve mobile-number updates with an OTP sent to the current number. Use a stronger second factor, re-verification, or in-person validation for high-risk changes.
• Bind authentication to the beneficiary and amount Make approval codes specific to the transaction so a replayed or redirected code cannot be used for a different payee or a different amount.
• Use cooling-off periods for newly trusted devices Limit first-time enrolments, high-value transfers, and rapid successive transactions until the device has a trust history and anomaly checks have had time to run.
• Review fraud rules and IAM controls together Align customer authentication policy, fraud detection, and access governance so device state, behavioural risk, and approval thresholds are enforced in one operating model.

Key takeaways

• The updated RMiT policy shifts authentication from a user convenience layer to a regulated fraud-control requirement.
• The key failure mode is channel trust, especially when SMS, device changes, or phone-number updates are treated as proof of legitimacy.
• The controls that matter now are device binding, transaction binding, and stronger verification around state changes, not just stronger login factors.

Key terms

• Device Binding: Device binding links a customer account to a specific approved device so that authentication and transaction approval are tied to that endpoint. In practice, it is a lifecycle control as much as a login control, because enrolment, replacement, and removal determine whether the binding remains trustworthy.
• Transaction Binding: Transaction binding means the approval code or authentication event is specific to the exact beneficiary, amount, or action being authorised. It prevents a reused or redirected approval from validating a different payment, which is a common failure mode in fraud-driven authentication attacks.
• Cooling-off Period: A cooling-off period is a temporary restriction applied after a new device or credential is enrolled, limiting high-risk actions until trust has been established. This reduces the value of freshly compromised access and gives fraud systems time to detect abnormal behaviour.

What's in the full article

Authsignal's full blog post covers the implementation detail this analysis intentionally leaves for the source:

• How the updated RMiT paragraphs map to specific authentication workflow changes across onboarding, device binding, and step-up verification
• The exact policy language around one-device-per-user defaults, mobile-number changes, and cooling-off periods for new devices
• How Authsignal positions its rules engine, passkey support, and risk-based flows against the RMiT requirements
• The operational examples that show how to translate fraud controls into an authentication architecture review

👉 Authsignal’s full post covers the control-by-control breakdown of device binding, MFA, and transaction verification.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.