We recently migrated our user base (12K+ people) from IIQ to ISC. Our primary account source is AD. We had already configured password expiration management and tested it in our staging tenant, with expected notification results. However, after our production migration, we received tickets about AD passwords having expired, with no notification from ISC.
Re-reading the docs, the only cause I can think of is this seemingly innocuous line:
To send a notification to users when their password expires, the user must be registered as an active user in Identity Security Cloud
All our migrated identities have “Identity State”: Active. However, 95% of them did not “register.” Does this in fact cause ISC not to send password expiration notifications? Is there any way to mark all our active identities as not just active, but “registered as an active user”?
@bjansen -
That line is exactly what’s biting you, and the direct answer to your second question is no: there’s no admin control that flips an identity straight to “registered.” Registration only happens when the person clicks the link in an invitation email and completes it. That’s a separate status from Identity State: Active, and per the password policy docs, expiration reminders get checked against the last password change in AD but only go out to identities that have actually registered. Active alone doesn’t cover it, which lines up exactly with what you’re seeing on the 95% who never registered.
Since you can’t set the flag directly, the fix is getting invitations out to that population. Per the docs on inviting users to register, there are two ways to do it: bulk-select the unregistered identities under Admin > Identity Management > Identities and use Actions > Invite Identities, or turn on automatic invitations on the relevant Identity Profile. The second option is probably the better fit for your numbers. The docs state automatic invitations apply to existing identities too, not just newly created ones, queued in batches of 1,000 every 30 minutes, so a 12K population would take a few hours to fully queue rather than needing to be pushed through the UI in one pass. Automatic mode also keeps nagging them, sending a reminder every 7 days until they register, where a manual invite just expires after 7 days and has to be resent by hand.
Worth treating registration completion as its own workstream for the rest of this migration rather than something to route around, since password expiration notification is gated on it by design, not a bug you can configure past.
Is there a way to bulk-mark everyone “registered”?
No — and this is by design, not an oversight. There’s no identity attribute or API field you can PATCH/aggregate your way into flipping to “registered,” because that status is meant to reflect that the person has actually proven who they are to ISC (via invite+credentials, or an authenticated SSO session
What you can actually do
Confirm the diagnosis first. Go to Search → Identities and run status:UNREGISTERED (optionally combined with source.name:"Active Directory" and attributes.cloudLifecycleState:active) to see exactly how many of your 12K are affected. This gives you a hard number and a target list.
Get people through registration/first-login, deliberately and soon:
Configure automatic invitations at the identity profile level, either on identity creation or when identities enter a given lifecycle state — this is the standard mechanism, and it queues invitations in batches of 1,000 every 30 minutes, plus sends registration reminder emails every 7 days until the user completes registration. For 12K people this will take some real time to fully cycle through, so start it now.
If you’re using SSO/pass-through authentication rather than the classic invite-and-set-password flow, you can configure pass-through authentication so users sign in with their existing network credentials instead of being prompted to set an ISC password — but they still need to actually land on ISC once (e.g., via an IdP tile/bookmark) to flip their status
Consider a short comms push (email/Slack/Teams) explicitly asking people to log into ISC once, since for a lot of your population this may be the fastest way to close the gap versus waiting on the invite cadence.
Stop-gap for anyone close to expiration right now: for identities still UNREGISTERED with an AD password nearing expiration, ISC’s built-in reminder won’t help them in time. A short-term workaround is a scheduled search/report (or a workflow triggered off a scheduled search) that flags AD accounts approaching their expiration window and sends a manual notification outside the standard password-policy reminder — since that path doesn’t depend on registration status the way the built-in feature does.
Longer term, once your invitation campaign has mostly caught up, re-run the status:UNREGISTERED search periodically to track the remaining gap and target reminders/support outreach at stragglers.
Identity State: Active is not the same as the ISC user status ACTIVE. SailPoint defines ACTIVE as a user who has registered and can sign in, while REGISTERED means they have set up a password but have not logged in yet (Working with Identities).
The password-expiration documentation specifically requires the user to be registered as an active user for notifications to be sent (Password Policies), so Identity State on its own does not satisfy that requirement.
I would check the affected identities’ actual ISC Status first. If they are UNREGISTERED, they need to be invited to register. If they are PENDING, they have already been invited but still need to complete registration.
Thanks for the confirmation that this is the problem. It’s insane that this feature requires everyone to log in to Sailpoint before it starts working. As I stated, we have 12K+ existing people. They do not have any reason to log in to ISC unless they happen to need to request a new entitlement. We are using SSO, so everyone “can sign in” without having registered first. We intentionally did not invite everyone to register because they are already onboarded. There is no reason to have everyone in the company “register” for a new app when they already have access.
I suppose we are going to implement our own password expiration notifier. Yet another ISC feature that is completely broken for us due to unreasonable implementation decisions.
Agreed. This is a miss. It is a design decision based on a presumptuous understanding about identity verification and how those considerations apply in organizations with established identity assurance capabilities. Especially given that there is no “power-user/advanced” work-around provided. Asking thousands of users to log into a system via SSO (with an already IAL verified credential!) to then effectively just close the window (because any info they would usually be asked to provide is already aggregated from authoritative systems) is… the definition of a meaningless wasteful step.