Certain characters are not supported as password inputs even if they are a part of UTF8-BMP3 character-set

Identity Security Cloud (ISC) ISC Discussion and Questions
,
2

@Shreya_Ray -

In Identity Security Cloud (ISC), passwords are effectively ASCII-only: letters A–Z/a–z, digits 0–9, and a fixed, documented set of special characters. Unicode “fancy” characters—including circled digits like ① (U+2460), emoji, CJK/Japanese characters, and other non-ASCII symbols—are not accepted by ISC’s password evaluator.

Here’s the relevant bit distilled from SailPoint’s docs:

  • ISC’s password policy UI defines what counts as letters, digits, and special characters.

    • Accepted specials are a fixed list: ~!@#$%^*()/_+-`={}\|][;?,.&><'" and space.

    • Passwords cannot include : or non-English characters (examples in the doc include £, ß, Ã). (Allowed Characters)

  • ISC also notes it “cannot process non-English characters as letters” and advises not to require a minimum letter count if you expect users to type such characters—reinforcing that non-ASCII characters aren’t recognized in evaluation. (documentation.sailpoint.com)

Why “①” fails, but some Japanese strings seemed to work

  • ① is outside ASCII and not in ISC’s allowed special-character list, so the evaluator rejects it. That’s expected per the table above.

  • If you’ve seen a Japanese password appear to “work,” it’s usually one of these cases:

    1. The change happened directly on the source (e.g., AD or an app) with looser rules, not through ISC’s evaluator; or

    2. The password contained only ASCII plus allowed specials, while the displayed value (e.g., masked or copied text) created confusion.
      ISC’s flow is: evaluate in ISC first, then send to the source only if it passes. So a true non-ASCII password shouldn’t pass ISC evaluation. (documentation.sailpoint.com)

UTF-8 vs. password rules (why the docs feel contradictory)

  • SailPoint does support UTF-8 for attributes and provisioning data (names, OUs, etc.), and SailPoint provides transforms to normalize/strip diacritics when needed. That’s separate from password input rules, which are intentionally conservative. (UTF-8 encoding support)

  • So: UTF-8 payloads? Generally OK. UTF-8 in passwords? No—stick to ASCII per the allowed set.

Practical guidance / what’s allowed

  • Allowed:

    • Letters: A–Z, a–z

    • Digits: 0–9

    • Specials: ~!@#$%^*()/_+-`={}\|][;?,.&><'" and space

  • Not allowed (examples): : and any non-ASCII symbol (e.g., ①, €, £, ß, ひ, emoji). (documentation.sailpoint.com)

If you must accommodate non-ASCII user input

  • You cannot “whitelist” additional Unicode characters in ISC passwords today. Instead:

    • Communicate ASCII-only rules in your password hints/help text.

    • If you’re transforming other identity attributes (e.g., for usernames/emails), use decompose/replace transforms to map diacritics to ASCII. (Community threads and examples show using decomposeDiacriticalMarks or replaceAll.) (SailPoint Developer Community)

Cheers!!!

1 Like