Preparing for the PDPC NRIC Authentication Ban: Migrating to Phishing Resistant MFA
As of 2026, private organizations in Singapore must stop using NRIC numbers for authentication by 31 December 2026, and the PDPC will enforce this requirement from 1 January 2027. Any system that uses a full or partial NRIC number as a password, a login ID, an OTP seed, or a default credential must move to a stronger method. The strongest available option is phishing resistant MFA, such as passkeys or hardware security keys. This blog deep dives into what you need in order to be prepared for PDPC NRIC Authentication Ban.
Key Takeaways on the PDPC NRIC Authentication Ban
The points below summarize what changed and what a security or compliance leader needs to do about it before the detailed walkthrough.
- The deadline is real and close. Private organizations must stop using NRIC numbers for authentication by 31 December 2026, and the PDPC steps up enforcement from 1 January 2027.
- The rule targets authentication, not identification. An organization can still use an NRIC number to identify or look someone up where it has a lawful reason, but it cannot use the NRIC to prove that a person is who they claim to be before granting access.
- Employee systems are also in scope. HR portals, payroll systems, and password-protected documents that use an NRIC number as a credential all fall under the same rule.
- Non-compliance is a PDPA breach. Continuing to authenticate with NRIC numbers can be treated as a failure to make reasonable security arrangements under the Personal Data Protection Act, which carries financial penalties of up to SGD 1 million, or 10% of annual turnover in Singapore, whichever is higher.
- Removing the NRIC is the floor, not the finish. Replacing an NRIC with a password plus an SMS code meets the letter of the rule but leaves the login phishable, so the stronger move is to adopt phishing-resistant MFA while the login flow is already being changed.
What the PDPC NRIC Authentication Ban Actually Requires
The PDPC NRIC authentication ban requires private organizations in Singapore to stop using NRIC numbers to verify a person’s identity, and it takes full effect on 31 December 2026. The Personal Data Protection Commission moved it there in stages. In June 2025 the PDPC and the Cyber Security Agency of Singapore issued a joint advisory telling organizations to stop using NRIC numbers to verify identity. In early 2026 the PDPC set the hard date, giving private organizations until 31 December 2026 to phase the practice out, after which, from 1 January 2027, the Commission steps up enforcement through directions and financial penalties. Government agencies have already moved off NRIC-based authentication, and sector regulators, including the Infocomm Media Development Authority, the Monetary Authority of Singapore, and the Ministry of Health, have issued their own guidance to the telecommunications, finance, and healthcare sectors.
The distinction the PDPC draws is the part that decides what an organization has to change. Identification is using a name or a number to tell people apart, and that use of the NRIC number is still allowed where there is a genuine need, subject to the usual limits on collection. Authentication is proving that the person in front of you is who they claim to be so you can grant access to their account, their records, or a service. Using an NRIC number for that second purpose is what the ban prohibits. The prohibited patterns are specific: a full or partial NRIC used as a password or login ID; an NRIC set as a default or initial password; an NRIC used as the seed for a verification code; and an NRIC combined with easily obtained details, such as a name or a birthdate, to form a credential like “567A01Jan80”.
An organization that handles personal data and still authenticates anyone with an NRIC number, whether a customer or an employee, can be found to have failed to make reasonable security arrangements under the PDPA. The obligation to protect personal data is closely aligned with how Singapore regulators treat access control, which we discuss in more detail in our section on what MAS auditors look for in your identity and access architecture.
Why NRIC Numbers Fail as an Authentication Factor
NRIC numbers fail as an authentication factor because an NRIC number is public information rather than a secret. A real authentication factor is something an attacker cannot easily obtain, whether a secret the user knows or a device the user holds. An NRIC number is neither, because it is printed on cards, written on forms, quoted for deliveries, and shared across everyday transactions, so anyone who can look it up can impersonate its owner.
Partial NRIC numbers are weaker still, because they fail even at telling people apart. The government has flagged that partial NRIC numbers are not reliable identifiers since two individuals can share the same partial number and, in some cases, the same name as well. A value that is neither secret nor unique is a poor control on both counts. That is why the fix is to stop using the NRIC number as an authenticator and put a real factor in its place, rather than masking more of its digits.
Why Ordinary MFA is Not Enough, and What Phishing Resistant MFA Means
Ordinary MFA is not enough because its most common forms, such as SMS codes and app-based one-time passwords, can still be phished in real time. Phishing-resistant MFA is the class of authentication methods that cannot be phished because they bind the login to the legitimate website using public-key cryptography, so the credential will not work on a look-alike site. Stolen credentials are exactly the risk this addresses. The Verizon 2025 Data Breach Investigations Report found that compromised credentials were the initial access vector in 22% of breaches, the single most common entry point, and that 88% of attacks on basic web applications used stolen credentials.
The specific weakness in code-based MFA is the adversary-in-the-middle attack. An adversary-in-the-middle attack places a fake login page between the user and the real service, then relays the password and the one-time code to the genuine site in real time, which defeats codes of every kind because the code is a shared secret the user can be tricked into handing over. Push-approval prompts have a related weakness since an attacker who already holds the password can send repeated prompts until a tired user taps “approve.”
Phishing-resistant MFA closes that gap by design. Guidance from CISA and NIST uses the term for methods that verify the site’s origin cryptographically, so there is no code to read out and no prompt to approve on the wrong site. Two families of technology meet the bar. The first is FIDO2 and WebAuthn, which covers passkeys and hardware security keys. The second is public-key infrastructure, meaning certificate-based or smart-card authentication. Everything else, including SMS codes, app-based one-time passwords, and simple push approvals, is stronger than an NRIC number but remains phishable.
Phishing Resistant MFA Options for Singapore Organisations
The phishing-resistant MFA options for Singapore organizations are passkeys, hardware security keys, platform authenticators, certificate-based or smart-card authentication, and Singpass or Myinfo for customer identity verification. The right method depends on who is logging in and how much assurance the system needs, and most organizations end up using more than one.
- A passkey is a FIDO2 credential stored on a phone or laptop that unlocks with a fingerprint, a face, or a device PIN, and it cannot be used on a fake site. Passkeys suit most workforce and customer logins and are supported across the major platforms and browsers.
- Hardware security keys are the highest-assurance choice and fit administrators, finance staff, and anyone with access to sensitive systems. A physical key that a user taps resists both phishing and device compromise, which is why privileged accounts are a natural place to start.
- Platform authenticators such as Windows Hello and the biometric unlock on Apple and Android devices provide passkey-grade protection using hardware the user already owns, which keeps rollout costs down.
- Certificate-based authentication and smart cards fit organizations that already run a PKI, and they are common in enterprise and government settings that need cryptographic identity tied to issued credentials.
- Singpass and Myinfo let Singaporean organizations verify a customer’s identity without asking for an NRIC number as proof, which moves the hardest part of identity assurance onto national infrastructure built for it.
How to Migrate from PDPC NRIC Authentication to Phishing Resistant MFA
Migrating from PDPC NRIC authentication to phishing-resistant MFA takes five steps: inventory every place an NRIC number acts as a credential; separate identification from authentication in each system; choose a phishing-resistant method for each user group; redesign enrollment and recovery so they do not reintroduce the NRIC; and remove the NRIC from every credential-generation path. The detail on each step is below.
Inventory first. Find every place an NRIC number is used to grant access, and look past the obvious login screen to default and initial passwords, the seeds behind verification codes, security questions, and password-protected documents such as encrypted statements and payslips. You cannot fix a use you have not found, and the document-password cases are the ones teams miss most often.
Separate identification from authentication next. Where an organization has a lawful reason to identify someone by NRIC number, that use can stay, subject to collection limits. Where the NRIC number is proving identity in order to open a door, that is the part to replace. Being explicit about which of the two a field is doing prevents a team from tearing out a lawful identification use or leaving a prohibited authentication use in place.
Then choose a phishing-resistant method for each user group, roll out enrollment, and design the recovery and fallback paths with care. Recovery is where phishing resistance usually breaks, because a weak “forgot my key” flow that falls back to an SMS code or an NRIC number quietly reopens the hole the migration just closed. Plan for call centers, shared devices, and users who are slower to adopt new technology, and give each a recovery route that holds the control. Finish by removing the NRIC number from every credential-generation path, including the scripts and templates that mint default passwords, and confirm the old authenticator can no longer be used.
The Singapore rules that touch identity and access rarely arrive one at a time, and this change sits alongside the wider expansion of the Cybersecurity Act, which we cover in navigating the expanded scope of Singapore’s Cybersecurity (Amendment) Act.
Mapping Each Prohibited NRIC Use to a Compliant Replacement
The table below turns the ban into concrete engineering changes. It pairs each prohibited pattern with the reason it fails and the replacement that satisfies both the rule and good security practice.
Identity hygiene
Replacing the NRIC as a credential
| Prohibited use of the NRIC | Why it fails | Compliant replacement |
|---|---|---|
| NRIC as a password or login ID | The value is public, so anyone who knows it can log in | A unique identifier unrelated to the person, plus phishing-resistant MFA |
| NRIC as a default or initial password | Predictable for every new user, and often never changed | A randomly generated single-use setup secret with a forced passkey enrolment |
| NRIC as the seed for a verification code | A code derived from a public value is not a real second factor | A FIDO2 passkey or hardware key, or at minimum an app-based code as an interim step |
| Partial NRIC combined with a name or birthdate | Guessable, and not even unique across individuals | An account identifier and authenticator that carry no personal data |
| NRIC as a document password for statements or payslips | Shared knowledge, so the protected file is open to many | A per-recipient random passphrase, or an authenticated portal that removes the file password entirely |
How Penetration Testing Validates Your New Authentication
Penetration testing validates your new authentication by attacking the login the way a real criminal would and measuring what happens. Choosing passkeys and writing the migration plan settles the design, and controlled testing confirms whether the deployed flow actually resists phishing. A test runs an adversary-in-the-middle proxy against the sign-in, tries to relay or replay the second factor, and probes the enrollment and recovery paths where phishing resistance most often quietly fails.
That testing also confirms the boring things that decide compliance. It checks that the NRIC number is genuinely gone from every authenticator path rather than surviving in a recovery fallback, a legacy admin screen, or a default-password script that nobody updated. A scanner will not tell you whether a “forgot my key” flow reintroduces an NRIC prompt, because that is a question about intended behavior rather than a known vulnerable pattern, and answering it takes a person reasoning through the flow. CredShields runs this as authenticated, human-led testing where every finding is reproduced and verified and the report carries a named assessor, and the same evidence supports an audit, which we describe in SOC 2 penetration testing and what you should expect before an audit. If validating your new authentication before the deadline is the gap, you can scope a penetration test against exactly those flows.
Technical Identifier Migration Framework: PDPC Technical Guide to NRIC Alternatives
A Migration Readiness Checklist Before the Deadline
Use this checklist as a fast self-assessment. It condenses the guidance above into the points most likely to decide whether an organization is compliant and secure on 1 January 2027.
Readiness checklist
An NRIC authentication readiness checklist for 2027
Use this checklist as a fast self-assessment. It condenses the guidance above into the points most likely to decide whether an organisation is compliant and secure on 1 January 2027.
You have run the full self-assessment. The NRIC is inventoried, separated, replaced, and owned, ready for 1 January 2027. The line most teams sign off on a config screen rather than in practice is testing the new flows against a real phishing simulation.
If item 09 is the gap, a human-led engagement can run a real phishing simulation against your new login and recovery flows, not only a configuration review, with every finding reproduced and signed by the researcher who found it.
Scope a phishing simulationFrequently Asked Questions (FAQs) About PDPC NRIC Authentication in Singapore
The questions below cover what security and compliance teams ask most often when they start planning this change.
It is the requirement that private organizations in Singapore stop using NRIC numbers to authenticate people. The PDPC set 31 December 2026 as the date to phase the practice out and will step up enforcement from 1 January 2027, treating continued misuse as a failure to make reasonable security arrangements under the PDPA.
You can still use an NRIC number to identify someone when you have a lawful reason and are subject to collection limits. What you cannot do is use it to prove identity in order to grant access, which is the authentication use the ban targets.
Removing the NRIC as the authenticator is what the rule requires, so a password plus an SMS code does meet the letter of it. An SMS code is not phishing-resistant, though, so it is a weak long-term choice, and while you are already changing the login, it is worth moving to a passkey or a hardware key instead.
Phishing-resistant MFA includes methods that use public-key cryptography to bind the login to the legitimate site, preventing fake sites from using the credential. In practice that means FIDO2 and WebAuthn, which covers passkeys and hardware security keys, and PKI, or certificate-based authentication such as smart cards.
Yes. HR portals, payroll and benefits systems, onboarding applications, and any encrypted documents sent to staff are all in scope if they use an NRIC number as a credential.
Because the misuse is treated as a breach of the PDPA’s reasonable-security-arrangements obligation, it sits under the PDPA’s financial penalty framework, where penalties can reach up to SGD 1 million, or 10% of an organization’s annual turnover in Singapore, whichever is higher.
Test it the way an attacker would. A phishing simulation against the live sign-in, plus checks on the enrollment and recovery paths, shows whether the second factor can be bypassed and whether the NRIC number is truly gone from every path, in a way a configuration review alone cannot.
Identification is using an NRIC number to tell who a person is, such as looking up a record, and it remains allowed where there is a lawful need. Authentication is using an NRIC number to prove a person is who they claim to be before granting access, and that is the use the ban prohibits. The rule turns on this distinction, so the fix is to keep lawful identification and replace every authentication use.
Yes, the NRIC authentication ban applies to all private organizations in Singapore regardless of size. A small business that uses NRIC numbers as passwords, login IDs, or default credentials has the same 31 December 2026 deadline and the same exposure to enforcement from 1 January 2027 as a large enterprise.
Yes, Singpass and Myinfo are compliant alternatives for verifying a customer’s identity, and they are often the simplest path for consumer-facing services. They move identity assurance onto national infrastructure designed for it, which removes the need to authenticate anyone with an NRIC number.
An organization can still use an NRIC number to identify who a caller is, but it cannot use the NRIC number on its own to prove the caller is that person before acting on the account. A call center should confirm identity with a factor the caller controls, such as a one-time code sent to a registered device or a passkey-based check, rather than treating a recited NRIC number as proof.
No, an authenticator app’s Time-Based One-Time Password (TOTP) is not phishing resistant. The TOTP code can be entered on a fake site, which then relays it to the real service, making it stronger than an SMS code but still phishable. Phishing-resistant methods such as passkeys and hardware security keys remove the code entirely.
Passwordless authentication is any login that does not rely on a typed password, and it satisfies the NRIC ban as long as it does not use an NRIC number as the credential. Not every passwordless method is phishing-resistant, since magic links and SMS codes are passwordless yet still phishable, so the strongest passwordless choice is a passkey or a hardware security key built on FIDO2.