Contents
Overview
If your organization is changing its outbound (egress) internet IP address ranges as part of a network modernization effort (often with a transition period where old and new IPs run in parallel, and legacy ranges may remain active for 6–12 months), Contently typically does not require any configuration changes. In this scenario, no error message is expected by default (none was reported).
This remains true as long as your SSO URL(s) stay the same, your identity provider (IdP) configuration remains unchanged, and your organization does not use a custom IP allowlist within Contently.
Key Information
- No Contently-side allowlist changes are needed when your outbound (egress) IPs change, unless your organization has configured a custom IP allowlist inside Contently.
- An outbound (egress) IP change on your network typically does not impact Contently SSO when:
- Your SSO URL(s) used for SAML/SSO remain the same.
- Your IdP configuration remains unchanged (metadata, certificates, entity IDs, ACS settings, bindings).
- No error is expected from the change notice alone. If SSO/login issues occur, they are usually caused by an unrelated configuration or policy dependency (commonly on the IdP side).
- Recommended validation is to test SSO during your parallel-run/testing window and confirm end-to-end login flows from networks that will use the new egress IP ranges.
- Based on the assessment for this scenario, no platform-side escalation is required to proceed with the network change.
Customer Impact
No action is required in Contently for an outbound (egress) IP range change if your SSO URL(s) and IdP configuration are not changing and there is no custom Contently-side IP allowlist.
Proceed with the network change and validate SSO during your planned test/cutover windows. If you have a transition period where old and new IPs run in parallel, use that window to confirm authentication remains stable.
What to confirm (quick checklist)
- Contently IP allowlist: Confirm whether your organization has a custom IP allowlist configured in Contently admin/security settings. If none exists, no update is needed.
-
SSO endpoints: Ensure your SSO URL(s)/endpoints are not changing (examples, generalized):
<your_sso_hostname>https://<your_sso_hostname>:443/<your_idp_sso_path>
- IdP configuration: Keep SAML metadata, certificates, entity IDs, ACS settings, and SSO bindings unchanged unless you are intentionally rotating/updating them as a separate effort.
How to validate after the change
- During the parallel-run/testing window, perform SSO login tests from user networks expected to be impacted by the new egress IP ranges.
- Confirm users can complete SSO and access Contently normally.
- If any authentication failures occur, capture:
- Timestamp(s)
- User impact scope
- Any IdP or browser error text
- Relevant IdP log excerpts (generalized/redacted as needed)
Frequently Asked Questions
- 1. How do I know if this applies to me?
- It applies when your organization is changing its outbound (egress) internet IP ranges and you’re concerned about Contently access/SSO impact. If you are not changing SSO URLs or IdP configuration, Contently typically requires no updates.
- 2. Is there a specific error message that indicates this problem?
- Not necessarily. An egress IP change notice alone may produce no error. If something is misconfigured elsewhere, you might see generic SSO/login failures; capture the exact IdP/browser error text and timestamps for investigation.
- 3. Do I need to update an IP allowlist in Contently when our egress IPs change?
- Only if your organization uses a custom Contently-side IP allowlist. If no custom allowlist is configured in Contently, no Contently-side IP updates are required.
- 4. What should we test during the transition period?
- Test SSO login end-to-end from networks that will start using the new egress IPs, and confirm users can authenticate and access Contently normally during the parallel-run window.
- 5. What if SSO starts failing after the egress IP change even though we didn’t change SSO URLs?
- Check whether your IdP has policies/conditional access rules tied to network/IP conditions, and verify certificates/metadata are unchanged. Collect timestamps and exact error text to correlate with IdP logs and authentication events.