I understand your confusion. You are mixing different things here, so let me try to separate them & walk through it.
Password policies in ISC apply to direct-connect sources only (not GitHub, since it’s not a directly connected source). These are rules that ISC enforces when a user changes their password through ISC’s Password Manager. The policy has to be associated with a source, and that source must be a direct-connect source that supports Password Management. Check these docs: Managing Password Policies & Password Requirements.
The Sign-in Method, Password Reset, and User Unlock settings in the Identity Profile are for how the user authenticates to ISC and the password reset flow (not GitHub). They do not decide how the user logs into GitHub or any other target application.
In your use case, the user gets GitHub access through Okta. GitHub is not a direct-connect source, and you’re not trying to apply a password policy to ISC login. So neither Password Policies nor the Sign-in Method apply here.
The actual login flow depends on how GitHub is configured:
If GitHub is integrated with Okta SSO: User goes to GitHub or clicks the Okta app tile → user is redirected to Okta → Okta handles authentication and MFA → user lands in GitHub.
If GitHub is using local GitHub authentication: User logs in directly to GitHub → GitHub’s own password and MFA policies apply.
So the number of MFA steps is not decided by SailPoint password policy. It is decided by the authentication provider in front of the application, usually Okta, Entra ID, or the target application’s own SSO and MFA settings.
Discover Applications in ISC helps bring visibility and governance around applications discovered from Okta or other SSO sources. It does not automatically make ISC the login provider for those apps.
So yes, it is use-case based. Configure it in the right layer:
Configure password policies in ISC only when users need to reset or change passwords through ISC for supported sources.
Configure the Sign-in Method on the Identity Profile to control how users authenticate to ISC itself.
If you want to control how the user authenticates to GitHub or how many MFA prompts they hit, that’s configured in your IdP (Okta, Entra ID, etc.) or the target application itself, not in ISC.
Configure ISC access profiles, roles, and provisioning if you want SailPoint to grant or remove the GitHub access.
Agree with Harish’s explanation here. I think the main confusion is between governance/provisioning and authentication.
From ISC perspective, password policies and password management features apply mainly to supported direct-connect sources where ISC is actually managing the password lifecycle. But for applications like GitHub that are accessed through Okta/Entra/Ping SSO, the authentication flow is usually controlled by the IdP layer, not by ISC.
So in a typical flow:
ISC handles provisioning/deprovisioning and governance
Okta/Entra/Ping handles authentication and MFA
The target application consumes the SSO assertion
That is why the number of MFA prompts, adaptive authentication behavior, session policies, etc. are generally decided by the IdP configuration and business use case.
Also, Discover Applications helps bring visibility and governance into ISC, but it does not automatically make ISC the authentication authority for those applications.
So yes, it is very much use-case based and depends on which layer is responsible for authentication in the architecture.
