Hi @ShoichiroK.00155 (LAC Co., Ltd)​ , Thank you for reaching out to the Okta Community! 

To answer your questions in short: 

"SSO Required" is a requirement of a complete Box implementation while continuous operation in "SSO Test Mode" is generally considered a security vulnerability.

Detailed explanation for use cases: "SSO Required" vs. "SSO Test Mode"

Why you should enable "SSO Required":

• Preventing Okta Bypass: If SSO is not strictly required, users can bypass Okta entirely and authenticate directly using a Box username and password (weak security).
• Enforcing Conditional Access: Box relies on Okta to enforce Multi-Factor Authentication (MFA), trusted IP ranges, and device trust. Bypassing Okta bypasses these critical security controls.
• Instant Offboarding: Disabling a user in Okta instantly severs their access to Box.
• Centralized Auditing: All authentication logs and anomaly detections are consolidated within your Identity Provider (Okta). (Check Okta System Logs Documentation for more details. )

Why you might intentionally avoid it (or use Test Mode):

• Active Rollouts: You are actively configuring SAML mappings or migrating users and need to ensure no one is locked out during the transition.
• Legacy App Dependencies: You rely on legacy third-party applications or scripts that use local Box passwords and cannot be upgraded to API keys, JWT, or OAuth.

Best Practices & Preventing Lockouts

Critical Limitation: Box does not natively allow you to exclude or exempt specific managed users (like IT Admins) from the "SSO Required" policy. Once enabled, the policy applies globally to all managed users under your corporate domains.

To mitigate the risk of being locked out:

1. Use an Unmanaged Break-Glass Account: Because the SSO requirement only applies to managed users (users on your claimed email domains), you can invite an external email address (e.g., a highly secured, non-corporate address) and grant it administrative privileges. This user will authenticate via Box directly, serving as an emergency backdoor if Okta goes down.
2. Okta Break-Glass Admins: Prevent the lockout at the source. Maintain at least one break-glass Super Admin account natively in Okta (excluded from other federated IdPs or strict network policies) to ensure you always have control over your side of the SAML configuration.
3. Box Support Contingency: In the event of a catastrophic Okta outage or an expired SAML certificate that locks everyone out, authorized admins can contact Box Support. Box can temporarily disable the "SSO Required" setting on the backend, reverting the tenant to local password access.
4. Test Thoroughly: Box considers enabling "SSO Required" a critical action. Before enforcing it, spend sufficient time in "SSO Test Mode" to ensure logins, Just-In-Time (JIT) provisioning, and attribute mappings function perfectly. 

If my answer helped, remember to mark it as best to increase its visibility for other members of the Okta Community who might have the same questions as you. 

Hope my answer helps! 

--

Help others in the community by liking or hitting Select as Best if this response helped you.

Collect them all. Learn a new skill and earn a new Okta Learning badge.

Just released: More Okta Community badges just added