Sure, thanks for looking into this. 1. With the current setup, each individual user is responsible for enabling MFA for their individual user account. It’s not currently possible to A) enforce MFA across the constant contact account determine if users have MFA enabled C) determine if the users password is compliant with org policy. The admin needs to “chase” the users to enable MFA, and the user then needs to maintain a separate form of MFA for Constant Contact. Likewise, there is no way to enforce a particular password policy to be compliant with the org’s standards. Additionally, the current setup requires that users must maintain a separate set of credentials, which adds complexity and complication to the existing setup and makes it more challenging for our users to adopt secure authentication practices.   With SAML Single Sign-On (SSO), users A) could be required to login through their Identity Provider (IdP) (Okta/Google Workspace, Azure AD etc.), don’t need to maintain a separate username/password/MFA and C) admins can ensure/attest that their constant contact accounts are secured according to policy because authentication has been set at the IdP level. 2. With regards to auto provision/deprovision, the use case would be essentially A) Being able to auto create Constant Contact users based on role (so for example marketing group), and when they get provisioned with the IdP and go to login to Constant Contact their account gets created. Being able to deprovision/delete users who are disabled from our IdP rather than having to log into the separate system and disable the user in both places. ... View more