IP Whitelisting for E-Signature: What It Covers and Its Limits

IP whitelisting, now often called allowlisting, lets an e-signature system accept traffic only from approved IP addresses. It works well for admin consoles, API endpoints and webhook receivers that people reach from a fixed office or server. It works badly for signers, who sign from phones, home Wi-Fi and coffee shops. The practical answer is to restrict the surfaces you control, and to protect signers with identity checks rather than network location.

This guide explains where an IP restriction belongs in an e-signature workflow, how to write the rules correctly, and what to layer on top. It also says plainly where BeeSign fits, so you do not assume a feature exists that we have not published.

TL;DR

• Allowlist the places where traffic comes from known addresses: your admin users, your API servers and your webhook endpoint. Do not allowlist signers.
• An IP address shows where a request came from, not who sent it. Pair any allowlist with strong authentication and least-privilege roles.
• Use the public egress IP your network presents to the internet, not a private address, and write single hosts as /32.
• If you run BeeSign with white-label and bring-your-own-cloud (BYOC), you can enforce IP rules at your own gateway or web application firewall.
• For signers, verify identity directly: government ID capture and face matching do what an IP list cannot.

Table of Contents

• What IP whitelisting actually does
• Which e-signature traffic is worth restricting
• Write the rules correctly
• Where an allowlist falls short
• Restricting the API and webhooks
• Enforcing IP rules when you run BeeSign on your infrastructure
• Protect signers without an IP list
• A rollout checklist
• Our perspective
• Run signing on your own infrastructure
• FAQ
• Sources

What IP whitelisting actually does

An allowlist is a list of IP addresses or ranges. A system checks the source address of each request and rejects anything not on the list. Web servers have done this for decades: the Apache access control documentation describes allowing a single address, a partial address or a network written in CIDR notation, for both IPv4 and IPv6.

In a SaaS context the same idea appears in a few forms:

• Application-level restriction. The product itself refuses logins or API calls from unlisted addresses. Microsoft’s Power Pages, for example, lets administrators restrict website access to a list of IP addresses, such as a corporate network.
• Edge-level restriction. A gateway or web application firewall sits in front of the application and filters by address. Cloudflare’s IP Access rules allow, block or challenge traffic by IP, network number or country.
• Outbound allowlisting. Your firewall permits traffic only to or from a vendor’s published addresses. This is the direction most readers mean when they ask for a vendor’s IP list.

These three are different controls with different owners. Mixing them up is the most common source of confusion.

Which e-signature traffic is worth restricting

An e-signature platform has several kinds of users and systems. Only some of them have stable addresses.

The signer row is the one that decides most design questions. A tenant signing a lease on a phone over cellular data has a different IP every time. Blocking by network would reject legitimate signers and do little to stop a determined fraudster, who can use any address.

Write the rules correctly

Most failed allowlists fail on details, not on concept.

Use the public egress address

A public SaaS service sees the address at its own edge, which is your network’s public egress IP. Private ranges such as 10.x.x.x or 192.168.x.x cannot be allowlisted for internet-facing access. To find the right address, make a request from the machine or office in question to an IP-echo service and record the result. If several offices or cloud workloads share a NAT gateway, you only need that one address.

Express hosts and ranges precisely

Write a single IPv4 host as a /32, for example 203.0.113.10/32. Use wider CIDR ranges only for ranges you control and that do not change. A range that is broader than you need quietly admits other tenants of the same provider. Microsoft’s connection filter documentation shows how strict parsers can be: for that email setting it accepts single IPs and ranges from /24 to /32, and it does not support IPv6. Always check what format the system you are configuring accepts.

Mind the list limits

Lists are finite. Exchange Online Protection, for instance, caps its IP allow and block list at 1,273 entries according to Microsoft’s service limits page. Other products set their own limits, so consolidate ranges you control rather than adding every address one by one.

Do not confuse email allowlisting with sign-in restriction

Searchers often land here from questions like how to whitelist an IP in Microsoft 365. That setting changes how Exchange Online filters incoming mail from those addresses. It affects whether a signing invitation lands in the inbox or the spam folder. It does not control who can sign in to an e-signature application. If signing emails are being filtered, the better fixes are to allow the sending domain and to use a branded sending domain, which BeeSign’s white-label option supports with custom domains and branded emails.

Where an allowlist falls short

A corporate IP is not an identity. Zero-trust research makes the same point: models that assume implicit trust inside internal networks are increasingly ineffective, and the alternative is continuous verification of identities, devices and applications. An allowlist can cut exposure from unknown networks, but it should sit alongside multi-factor authentication, session controls and least privilege.

Three specific weaknesses matter for signing workflows:

1. Shared addresses. Everyone behind the same office NAT or VPN exit looks identical. A compromised laptop in an approved office passes the check.
2. Rotating addresses. Remote staff, mobile users and some cloud workloads change addresses. Each change either locks someone out or tempts an admin to widen the list.
3. Global exceptions. Cloudflare warns that allowing an IP globally can bypass several other configured security rules. Scope an exception to the one hostname or path that needs it.

For legal validity, network location also adds little. What makes a signature hold up is intent, consent, attribution and a reliable record, as we explain in what makes an eSignature valid. The IP address captured in an audit trail is one piece of evidence among several, not the proof of who signed.

Restricting the API and webhooks

If you automate agreements with the API, this is where an allowlist pays off most. Your calling servers usually have fixed addresses, so the list is short and rarely changes.

A sensible layering looks like this:

1. Keep the API key secret. Treat it like a password: store it in a secrets manager, never in client-side code or a repository.
2. Restrict at your own edge. Route calls through a gateway you control and allow only your servers’ egress IPs to reach the internal service that holds the key.
3. Verify webhook signatures. For inbound webhooks, signature verification is the primary check. An IP filter is an optional second layer, and it needs maintenance if the sender’s addresses change.
4. Handle replays and retries. Time-limited requests and sensible retry behavior stop captured calls from being reused. Our posts on e-signature API security and the five-minute replay window and on server actions that prevent retry amplification cover both.
5. Monitor the endpoint. If your webhook receiver sits behind a gateway you operate, watch its certificate as well as its address. A tool such as certificate expiry monitoring alerts you before an expired certificate silently breaks callbacks.

A worked example: a property management company calls the API from two application servers behind one NAT gateway at 203.0.113.10. Its gateway accepts requests to the internal signing service only from 203.0.113.10/32, the service authenticates with a scoped key, and webhooks arrive at a separate path that checks the signature. Losing the key is no longer enough for an outsider to create or send agreements. They would also need to come from that address.

Enforcing IP rules when you run BeeSign on your infrastructure

Restrictions at the vendor’s edge depend on the vendor exposing the control. We do not publish a tenant-level IP allowlist setting for our hosted product, so if you need one, confirm your exact requirement with us before you design around it.

What you can do is run the service under your control. With white-label and BYOC, the platform runs under your own branding and custom domain, with storage in your own cloud. When the entry point is a domain and infrastructure you operate, you can put your own perimeter in front of it:

• A web application firewall. AWS WAF supports custom IP-match rules for web applications and APIs, and AWS guidance on restricting access by IP or geolocation describes regional and global web ACL patterns.
• A CDN or reverse proxy. Cloudflare custom rules can allow, block or challenge by address. Use narrowly scoped rules for specific paths such as /admin or /api, not one broad exception.
• Separate paths for separate audiences. Allow the admin and API paths only from known addresses. Leave the signing path open, because signers cannot be predicted.

That last point is the whole design in one line: restrict the console and the API, keep signing reachable, and verify the signer another way.

Protect signers without an IP list

Signers are the part of the workflow where an allowlist cannot help, so use controls that follow the person instead of the network:

• Unique, expiring signing links tied to one recipient.
• Government ID capture and biometric face matching for agreements where you must be sure who signed. See our guide to how to verify signer identity online and the 2026 security guide to identity verification in eSigning.
• A complete audit trail that records the sequence of events for each document.
• Encryption in transit and at rest, described on our security page.

If your reason for asking about IP restrictions is “we need to be sure the right person signed,” identity verification answers that more directly than any network rule. Our overview of document signing with identity verification walks through how it fits into a signing flow.

A rollout checklist

1. List every system and person that touches the platform: admins, API servers, webhook receivers, approvers.
2. Mark which of them have a stable public egress IP. Everyone else needs a different control.
3. Record the exact egress addresses and write each as /32 unless you own a wider range.
4. Add rules at the narrowest scope possible: one path, one hostname, one purpose.
5. Test from an approved and an unapproved network before enforcing, and keep a break-glass admin route that does not depend on the list.
6. Put a named owner and a review date on the list. Remove addresses when an office closes or a server is retired.
7. Add MFA or SSO, scoped roles and monitoring so the list is never your only defense.

The break-glass step matters. Lock yourself out of an admin console with a mistyped address and you will need a support path that works from anywhere.

Our perspective

We get asked about IP restrictions mostly by IT and operations managers who want to reduce exposure, and by teams in regulated settings who need to show a control to an auditor. Our view is that the instinct is sound but the target is often wrong. The risky moments in an agreement workflow are who is signing, who can change a template, and who can call the API. Only the last two have stable addresses.

That is why we build around identity and ownership of infrastructure. Identity verification checks the person. White-label and BYOC let you keep the domain, branding and document storage inside your own environment, so your own firewall rules, logging and retention policies apply to it. We also build and maintain integrations for clients, so your API connections do not become another unmanaged surface.

Our advice is to be honest about what each control proves. An allowlist proves a request came from a place. A verified signature proves a person agreed. Use both where they fit, and do not ask one to do the other’s job.

— Mustafa Abusharkh

Run signing on your own infrastructure

If your security team wants control over the domain, storage and network perimeter, look at BeeSign White Label & BYOC. It covers custom domains, branded emails and storage in your own cloud. Plans and the 7-day free trial are on the pricing page, where the Individual plan is $9.99 per month. Enterprise and customized integrations are quoted to your requirements.

FAQ

Is IP whitelisting the same as IP allowlisting?

Yes. Allowlisting is the newer term for the same practice: permit access only from approved addresses or ranges. Documentation from vendors uses both, so search for either when you look up a setting.

Should I restrict signers by IP address?

No. Signers use changing networks, and an IP does not prove who they are. Use unique signing links, identity verification and an audit trail instead, and reserve IP restrictions for admin and API access.

Can I whitelist an IP in Microsoft 365 to receive signing emails?

You can add sender addresses to an Exchange Online connection filter, which changes how mail from those IPs is treated. It does not affect who can log in to a signing application. A branded sending domain is usually the more durable fix for delivery problems.

Does an IP allowlist replace multi-factor authentication?

No. A network address is not an identity, and shared offices or VPNs make many people look the same. Treat the list as one layer next to MFA, SSO and least-privilege roles.

Sources

• Access Control, Apache HTTP Server 2.4
• Restrict website access by IP address, Microsoft Learn
• Set-HostedConnectionFilterPolicy, Microsoft Learn
• Exchange Online Protection limits, Microsoft Learn
• IP Access rules, Cloudflare WAF docs
• Restrict access based on IP address or geolocation by using AWS WAF
• Zero Trust Architecture in Cybersecurity, Computer Fraud and Security

Recommended

• Are Electronic Signatures Legally Binding? Everything You Need to Know
• What Makes an eSignature Valid?
• eSignature Compliance Checklist for Teams