Why does Singpass Myinfo matter for security teams?

Why Myinfo changes the security posture of digital onboarding

Myinfo matters because it changes the trust model for onboarding. Instead of collecting personal data from the user and then trying to verify it later, a service can retrieve data that has already been verified by a trusted source. That reduces manual checks, but it also makes the retrieval flow, consent handling and downstream reuse of data security-critical.

For security teams, the important shift is that Myinfo is not just a convenience feature. It becomes part of the identity and data-handling path for account creation, profile population and access decisions. That means the design has to assume that mistakes in consent scope, API trust boundaries or session handling can have direct account-integrity and privacy consequences.

Myinfo also affects how much data enters the environment at once. If a service asks for more attributes than it genuinely needs, the security problem is not only privacy over-collection, but also larger blast radius if the onboarding session, API token or receiving application is abused. That is why data minimisation and permission scoping belong in the security review, not only in the product discussion.

Consent, API permissions and session controls

Security review should focus on three linked controls: the consent screen, the API authorisation model and the session that carries the user through onboarding. The consent flow should be specific enough that a user can understand what data is being released and to which service, while the API permissions should be narrow enough that one integration cannot silently expand into another use case.

Session security matters because onboarding is a high-value transaction path. If an attacker can hijack an authenticated session, reuse a token, or exploit weak redirect handling, they may be able to pull verified data into an unauthorised account creation flow. That is a different risk from ordinary web login risk because the stolen session can carry trusted identity data into a new service relationship.

The service consuming Myinfo also needs clear internal ownership for how returned attributes are stored, logged and forwarded. A common failure mode is treating the retrieved data as if it were already "safe" because it came from a trusted source. In practice, the receiving system still needs controls for access restriction, retention, masking and auditability.

What security teams should watch for after integration

The security value of Myinfo is highest when it is used to reduce fraud and reduce friction at the same time. It becomes risky when teams assume the presence of a trusted identity source eliminates the need for fraud controls, anomaly detection or post-onboarding validation. Verified data can still be misused if the surrounding application allows weak account recovery, poor session binding or excessive attribute exposure.

Security teams should also watch for misuse patterns such as repeated onboarding attempts, unusual attribute requests, account creation from inconsistent device or network patterns, and mismatches between the retrieved identity data and later account behaviour. Those signals help distinguish legitimate digital onboarding from attempts to create fraudulent accounts with trusted attributes.

For the broader API and data flow, the strongest external references are the OWASP API Security Top 10 for broken authorisation and API misuse, and the NIST Privacy Framework for controlling collection, use and sharing of personal data. For identity assurance and onboarding assurance decisions, the NIST SP 800-63 Digital Identity Guidelines provide a useful reference point.

Risk and Threat Considerations

Myinfo reduces onboarding friction, but it also concentrates trust into a single data-retrieval path. If consent is too broad, permissions are overexposed or the onboarding session is compromised, an attacker may gain enough verified data to create accounts, impersonate users or enrich fraud at scale.

Failure mechanism: Weak consent scoping, broken API authorisation or session compromise can let a service retrieve more verified data than intended, or let an attacker trigger legitimate retrieval for an illegitimate account creation flow.

Impact: The likely consequences are excessive personal data exposure, fraudulent account creation, identity abuse and a harder incident response problem because the data came through a trusted channel.

Practitioner Guidance

What to verify: Confirm that each Myinfo integration requests only the attributes required for the exact onboarding use case, and that the consent text matches the actual data release path. Treat any mismatch between user-facing consent and backend data access as a release blocker.

Decision rule: If the receiving application can create an account, bind recovery factors or populate risk signals from Myinfo data, require stronger review of API permissions, session binding and downstream storage controls before production go-live.

What good looks like: The onboarding flow should be narrow, auditable and revocable, with clear evidence of who requested data, what was released, when it was used and where it was stored. If those answers are hard to produce, the integration is not yet security-ready.

Practitioner takeaway: Treat Myinfo as a trusted identity input, not a blanket trust decision, because the real security boundary is the combination of consent, permission scope, session integrity and downstream data handling.

Related resources from NHI Mgmt Group

• Guide: Digital Identity, eID and Identity Wallets Guide
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?