- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
an hour ago
When integrating ServiceNow with SaaS applications (M365, Adobe, DocuSign, Salesforce, Informatica), don't assume cloud-based = no IP whitelisting needed. Many enterprises have IP-based Conditional Access or security restrictions enabled on their SaaS integrations. This can impact your go-live timeline if not validated upfront.
I recently worked on a large SAM Pro engagement and initially assessed the SaaS integrations as having "no impact" from a network infrastructure change.
After reviewing the customer's integration architecture diagram, I discovered that their M365 SAM integration uses Azure Conditional Access with IP-based restrictions. When the infrastructure changed and new IP ranges were introduced, they had to be whitelisted in Azure's Named Locations policy, or the M365 scheduled discovery jobs would fail.
Why This Matters
This isn't just an M365 issue. After investigating, I confirmed that all major SaaS platforms support IP whitelisting/restrictions:
- Microsoft 365 / Azure - Conditional Access with Named Locations
- Adobe Creative Cloud - IP-based access control
- DocuSign - IP Address Restrictions
- Salesforce CRM & Marketing Cloud - Trusted IP Ranges
- Informatica Cloud - IP Allowlisting + IP Filtering Policies
If your customer has enabled these security controls (which is common in regulated industries like banking, healthcare, finance), then firewall/IP changes can block your integrations.
Official Vendor Documentation
Here are the official references proving each platform supports IP whitelisting:
MICROSOFT 365 / AZURE CONDITIONAL ACCESS
What it does: Restricts service principals (like ServiceNow's Graph API connector) to specific IP ranges via Named Locations and Conditional Access policies.
Reference: https://learn.microsoft.com/en-us/entra/identity/conditional-access/workload-identity
Key takeaway: If the customer has configured Azure Conditional Access for their ServiceNow integration service principal, you MUST update the Named Locations policy when IP ranges change.
ADOBE CREATIVE CLOUD
What it does: IP-based access control allows admins to restrict Adobe product access to trusted IP ranges only (up to 150 CIDR ranges).
Reference: https://helpx.adobe.com/enterprise/using/ip-based-access.html
Key takeaway: Ask the Adobe admin if IP-based access is enabled. If yes, ServiceNow's integration IP must be whitelisted.
DOCUSIGN
What it does: IP Address Restrictions allow organizations to restrict access by IP at the Login, API, or Full level (100-unlimited ranges depending on plan).
Reference: https://www.docusign.com/trust/security/clm
Key takeaway: DocuSign supports granular IP restrictions. Confirm with the DocuSign admin if they've enabled this for your ServiceNow integration.
SALESFORCE CRM & MARKETING CLOUD
What it does: Trusted IP Ranges security control allows admins to restrict API access and user sign-ins to specific IP addresses.
Reference: https://help.salesforce.com/s/articleView?id=sf.connected_app_edit_ip_ranges.htm
Key takeaway: If Trusted IP Ranges are enabled in Salesforce setup, the ServiceNow integration IP must be whitelisted.
INFORMATICA CLOUD
What it does: IP Allowlisting for Application Integration + IP Filtering Policies for APIs allow organizations to restrict access to known IP ranges.
Key takeaway: If the customer uses Informatica Cloud, they likely have IP restrictions configured. Confirm with Informatica admin.
The Critical Distinction
Vendor capability ≠ Actual configuration
Just because a platform can support IP whitelisting doesn't mean the customer HAS enabled it. However, in regulated industries (banking, healthcare, finance), IP-based security controls are common.
You CANNOT confirm if IP restrictions are enabled without:
- Reviewing the customer's architecture diagrams
- Asking the platform owners (Azure, Adobe, DocuSign, Salesforce, Informatica admins)
- Checking the actual security policy configuration
Vendor documentation alone won't tell you if the customer has IP restrictions enabled only their architecture and configuration will.
Practical Checklist for SAM Pro Engagements
When scoping SaaS integrations (M365, Adobe, DocuSign, Salesforce, Informatica), ask upfront:
Do you have architecture diagrams for each SaaS integration? (Diagrams should show authentication method, IP restrictions, conditional access policies, etc.)
M365: Does Azure have Conditional Access configured for the ServiceNow service principal?
Adobe: Is IP-based access control enabled in Adobe Admin Console?
DocuSign: Are IP Address Restrictions configured in DocuSign settings?
Salesforce: Are Trusted IP Ranges enabled in Salesforce setup?
Informatica: Are IP Allowlisting or IP Filtering Policies configured in Informatica?
Ownership: Who owns the firewall/IP whitelisting for each platform? (Usually IT/Security/Platform teams)
Change process: What's the approval/change management process for updating IP whitelists?
Timeline: If network conditions change, what's the SLA for updating whitelists?
Lessons Learned
DON'T ASSUME CLOUD = OPEN ACCESS
Enterprise security postures often layer multiple controls: authentication (OAuth, certificates), authorization (roles), AND network restrictions (IP whitelisting). Just because something is "cloud-based" doesn't mean it's open to the internet.
REQUEST ARCHITECTURE DIAGRAMS UPFRONT
Ask for integration architecture diagrams at the discovery phase, not during implementation. Include:
- Which systems are cloud vs. on-premise
- Which systems have IP restrictions
- Which IP ranges are currently allowed
- Who owns each system
VALIDATE WITH PLATFORM OWNERS
Don't rely on IT generalists. Talk to the actual platform owners:
- M365: Azure team
- Adobe: Adobe admin
- DocuSign: DocuSign integration owner
- Salesforce: Salesforce admin
- Informatica: Informatica admin
CHECK FOR INFRASTRUCTURE CHANGES
When vendors announce infrastructure changes (IP ranges, endpoints, etc.), immediately check if your customer has IP-based restrictions configured. If yes, this becomes a critical change management item.
BUILD IP WHITELISTING INTO YOUR DISCOVERY
Add a discovery question: "Does your organization use IP-based security restrictions on any SaaS applications?" This simple question prevents surprises later.
Real-World Impact
In my recent engagement:
Issue: Infrastructure change required new IP ranges
Impact: SAM scheduled discovery jobs would fail if IP whitelisting wasn't updated
Solution: Security team updated configuration to include new IP ranges
Timeline: Limited window from discovery to remediation
Risk: If we hadn't caught this during discovery, the go-live would have been blocked
This is a real blocker, not just a "nice to know."
Conclusion
Cloud SaaS is not the same as "open to the internet." Enterprise security teams often layer IP-based restrictions on top of modern authentication. When you're scoping SAM Pro engagements, don't assume no IP whitelisting is needed. Ask upfront, validate with platform owners, and request architecture diagrams.
This simple due diligence step can save you weeks of troubleshooting and prevent go-live delays.
What's your experience? Have you run into IP whitelisting issues with SaaS integrations? Share in the comments I'd love to hear how this showed up in your engagements.
Regards,
Abby
