TL;DR: Bank Negara Malaysia’s updated RMiT policy tightens requirements around device binding, phone-number changes, cooling-off periods, and MFA resistant to interception, turning prior fraud guidance into mandatory controls for Malaysian financial institutions, according to Authsignal. The compliance question is now whether authentication architecture can bind transactions, devices, and trust state tightly enough to outpace account takeover tactics.
At a glance
What this is: This is Authsignal’s analysis of Bank Negara Malaysia’s updated RMiT policy, which raises the bar on authentication, device binding, and fraud-resistant transaction controls for Malaysian financial institutions.
Why it matters: It matters because IAM teams in regulated financial services must now align user authentication, device trust, and transaction verification with mandatory controls that outgrow SMS OTP and other weak binding patterns.
Context
Bank Negara Malaysia’s updated Risk Management in Technology policy resets the baseline for customer authentication in Malaysian financial services. The policy reaches banks, insurers, e-money issuers, and payment system operators, and it treats device binding, phone-number changes, cooling-off periods, and phishing-resistant MFA as governance issues rather than optional fraud controls.
The core problem is familiar across identity programmes: authentication that proves a user once is not enough when fraudsters can hijack the channel, swap the device, or alter the transaction after approval. This is a human IAM and customer authentication issue, but the design lessons apply equally to any programme that still trusts a session more than the transaction state.
Key questions
Q: What breaks when banks rely on SMS OTP as the only transaction authentication method?
A: Banks expose themselves to account takeover and transaction fraud because a stolen or relayed OTP proves only that a code was received, not that the session, device, or transaction is trustworthy. Once the attacker controls the channel or the user is socially engineered, the code becomes a weak hurdle rather than a real assurance step.
Q: Why do device binding and transaction binding need to be designed together?
A: Device binding limits which device can act, but transaction binding limits what that device can approve. If you only bind the device, an attacker with control of that device can still alter beneficiaries or amounts after authentication. Binding both the endpoint and the transaction narrows the fraud window materially.
Q: When should banks prioritise passkeys over SMS or push MFA?
A: Banks should prioritise passkeys when the main goal is to reduce phishing and credential replay while also improving completion rates. SMS and push can still serve edge cases, but they preserve more of the old trust model. Passkeys become the better default when the bank can support a phased rollout and reliable recovery.
Q: How should teams govern device enrolment after a new phone or secure device is added?
A: Treat enrolment as a low-trust state until the device proves itself through time, behaviour, and step-up verification. That means temporary transaction limits, tighter monitoring of high-value activity, and explicit review of any exception that expands trust too quickly after registration.
Technical breakdown
Why SMS OTP no longer satisfies assurance requirements
SMS OTP fails because the authentication factor rides the same phone number and delivery path that attackers now target. SIM-swap attacks, message interception, and silent code deletion make the code visible to the fraudster or invisible to the customer. Once the number itself becomes the compromise vector, the factor no longer proves possession in any meaningful way. RMiT’s move away from unencrypted SMS reflects a broader identity lesson: channel security and identity assurance are not the same thing.
Practical implication: treat SMS as a legacy fallback, not a primary factor, for regulated transactions and sensitive account changes.
How device binding and transaction binding work together
Device binding ties the account to a trusted device, while transaction binding ties the authentication event to a specific beneficiary and amount. Those are different controls. Device binding limits which endpoint can initiate activity; transaction binding prevents an attacker from reusing a valid approval for a different payee or value. In practice, this shifts assurance from the login moment to the actual payment or change request, which is where fraud often occurs.
Practical implication: align your authentication layer with the transaction object, not just the user session.
Why cooling-off periods are now part of authentication design
Cooling-off periods add a time-based trust gate after first enrolment or a device change. They recognise that a newly bound device has little behavioural history and should not immediately receive full transaction authority. Combined with velocity limits and abnormal-pattern checks, the control creates a temporary low-trust state that narrows the attacker’s window after takeover. This is a governance control as much as a fraud control, because it formalises when trust should expand.
Practical implication: design post-enrolment limits as a default control state, not as an exceptional manual review.
Threat narrative
Attacker objective: The attacker’s objective is to seize customer trust state and use it to approve fraudulent transactions that appear legitimate to the institution.
- Entry begins when fraudsters intercept or redirect SMS authentication codes through SIM-swap or message interception techniques.
- Credential use follows when attackers authenticate successfully with a code the customer never reliably controlled.
- Escalation occurs when the attacker adds a new device, changes a phone number, or increases transaction authority on the compromised account.
- Impact is fraudulent transaction execution, account takeover, or rapid draining of customer funds before detection.
Breaches seen in the wild
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Transaction-bound authentication is now the real control boundary: RMiT is not just asking institutions to strengthen MFA, it is forcing them to prove that authentication is attached to a specific transaction, beneficiary, and amount. That matters because many fraud controls still validate the session rather than the value being moved. The practical conclusion is that transaction state, not login state, has become the security object that matters most.
Device trust must be treated as revocable, not assumed permanent: The one-device-per-user default reflects a deeper governance shift. A trusted device is not a stable identity attribute when SIM swaps, device migration, and account recovery flows can all reassign trust. Financial institutions should read this as a mandate to manage device trust as a lifecycle control, not a one-time enrolment event.
Cooling-off periods expose the weakness of immediate trust expansion: The policy assumes that a newly enrolled device has not yet earned the same authority as an established one. That assumption breaks many existing authentication architectures, which grant full capability as soon as enrolment succeeds. The implication is that assurance must now grow over time, not arrive all at once.
Cryptographic authentication is becoming the compliance floor for retail finance: The requirement for digital certificate or passwordless options shows where the market is headed. Password-based and SMS-based flows are increasingly out of step with supervisory expectations, especially where fraud can be automated across channels. IAM teams in regulated sectors should expect stronger pressure to make phishing-resistant methods the default.
Fraud prevention and IAM are converging into one control plane: RMiT treats authentication, device binding, abnormal transaction detection, and verification of sensitive changes as a connected system. That is the right model for modern financial identity governance. The practical takeaway is that teams can no longer separate login security from transaction security and still claim coherent control coverage.
What this signals
Device binding has become a governance control, not just an antifraud setting: Financial institutions need a formal trust model for what a newly registered device can do, how long it stays constrained, and which events can expand its authority. That is a lifecycle question for customer identity, not a narrow product setting.
Phishing-resistant authentication is now the expected baseline for high-risk financial actions: The policy direction makes clear that assurance anchored in unencrypted SMS is no longer defensible where account takeover and channel manipulation are realistic. IAM teams should assume that transaction risk will increasingly drive authentication architecture.
Identity teams should align recovery, enrolment, and payment approval paths: If a phone-number change, new device enrolment, and payment approval are governed by different rules, attackers will target the weakest transition. Cohesive policy across those journeys is what converts authentication from a login control into a fraud barrier.
For practitioners
- Replace SMS OTP as the primary factor Move regulated customer journeys toward phishing-resistant MFA, including passkeys or certificate-based authentication, and reserve SMS for low-risk fallback use only where policy permits.
- Enforce one-device-per-user by default Build device registration and unbinding flows that make single-device binding the default, with explicit customer opt-in and audit logging for any multi-device exception.
- Bind approvals to the transaction details Make authentication codes specific to the confirmed beneficiary and amount so a reused approval cannot authorise a different payment or altered transfer instruction.
- Add verification gates for phone-number changes Require identity re-verification or stronger step-up checks before a mobile number change is accepted, rather than relying on the current number as proof of control.
- Apply cooling-off and velocity limits after enrolment Treat first-time device enrolment as a low-trust state, with temporary transaction caps and abnormal-pattern controls until behaviour establishes confidence.
Key takeaways
- The policy raises authentication from a convenience layer to a regulated control surface for Malaysian financial institutions.
- Its practical effect is to push teams away from SMS-era assurance and toward device-bound, transaction-specific, phishing-resistant authentication.
- Institutions that cannot bind trust to the device, the transaction, and the change request will struggle to meet the new standard cleanly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on replacing weak authentication channels in regulated financial services. |
| NHI-05 — Overprivileged NHI | Device enrolment and transaction authority must be constrained to the minimum necessary trust state. | |
| Recommendation — Replace SMS-based authentication with phishing-resistant methods for regulated customer transactions. Limit newly enrolled devices to the minimum transaction authority until trust is re-established. | ||
| NIST SP 800-63 | SP 800-63B — Authentication | The policy shift aligns with stronger authenticators and resistance to interception. |
| Recommendation — Adopt authenticators that resist interception and bind authentication to the intended transaction. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article focuses on managing authenticators across enrolment, change, and verification flows. |
| Recommendation — Manage credential and authenticator lifecycle controls so changes require stronger verification. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The update changes how access rights and authorisations are assigned after device enrolment. |
| Recommendation — Align authentication events with authorisation limits so new devices do not inherit full trust immediately. | ||
Key terms
- Device binding: A control that links an authenticator or key pair to a specific endpoint so the same secret cannot be copied and reused elsewhere. It strengthens assurance, but the binding step itself becomes a high-value target if attackers can intercept the enrollment process.
- Transaction binding: Transaction binding links a user's identity, the document they approved, and the workflow state into a single evidence record. This matters in digital lending because a signature alone is not enough to prove the right person approved the right version at the right stage.
- Phishing-Resistant MFA: Phishing-resistant MFA uses authentication factors that cannot be easily replayed, intercepted, or socially engineered. In regulated environments, this usually means device-bound or cryptographic methods rather than push prompts or SMS codes, because the control must hold up under realistic attack conditions.
- 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.
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.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org