IP Allowlist
The IP allowlist restricts who can sign in to the portal based on the network address they are connecting from. When it is switched on, a correct email and password are not enough — the request also has to arrive from an address you have approved.
Find it under Admin Center → IP access.
Before you switch it on
The page shows your current address at the top. Every decision on this screen comes down to "does this list still include me?", so check that value first. There is an Add it to the list link next to it that adds your current address as a range, which is the safest way to start.
Decisimo will not let you lock yourself out. It refuses to save if:
- the switch is on but no ranges have been entered, or
- your own current address is not covered by the list that would apply to you.
If you see one of those refusals, nothing has been saved — correct the list and try again.
Turning the feature off is never blocked. That is always the way out.
Allowed ranges
These apply to everyone in your organization. Each row takes:
- A single address —
203.0.113.9 - A CIDR range —
203.0.113.0/24covers203.0.113.0through203.0.113.255
IPv6 is supported in both forms (2001:db8::1, 2001:db8::/32). An IPv4 address never matches an IPv6 range, or the other way round.
The table always keeps one empty row at the bottom — start typing in it and a new one appears, so there is no button to press. The trash icon on a row removes it, after a confirmation.
The optional note beside each range is for your own reference — "Prague office", "VPN exit" — and has no effect on matching.
Ranges are stored in their canonical form. If you enter 10.0.0.7/24, it is saved and displayed as 10.0.0.0/24, because those two select exactly the same addresses. This keeps one rule from appearing twice under different spellings.
Per-user exceptions
An exception pins one person to their own set of ranges — useful for a contractor who should only reach the portal from one address.
An exception replaces the allowed ranges for that person; it does not add to them. If someone has an exception listing 198.51.100.5, that is the only address they can sign in from, even if the organization-wide list is much wider. This is deliberate: a rule that quietly widened them back out would defeat the point of pinning them.
Letting someone sign in from anywhere
Tick Allow sign-in from any address on an exception to exempt that person from the restriction entirely. It writes the two ranges that together mean "everywhere" — 0.0.0.0/0 and ::/0 — because a /0 only matches its own address family: 0.0.0.0/0 on its own would still block that person the moment they connected over IPv6. Decisimo refuses to save one without the other for the same reason, wherever you enter it.
Unticking puts their previous ranges back. If the exemption was granted in an earlier session there is nothing to put back, so unticking clears the exception and returns them to the organization-wide ranges.
Removing an exception returns that person to the organization-wide ranges. So does deleting its last row — an empty exception is simply the absence of one, never a rule that denies everything.
Ranges and exceptions are removed through a confirmation dialog rather than a single click, since one row of digits looks much like another.
What a blocked person sees
Someone signing in from an address that is not allowed is told that sign-in from their network is not permitted and to contact their administrator. They are not told that their password was wrong, because it was not.
If they were already signed in when the list changed, their session stops working and they are returned to the sign-in screen, where they get the same explanation.
Blocked sign-in attempts are recorded in the audit log as login_blocked_ip, along with the address that was refused. This is worth checking if someone reports they cannot get in — and it is the only trace such an attempt leaves, since the credentials themselves were correct.
What it covers
The allowlist applies to portal sign-in, and it covers every route in: password sign-in, single sign-on, and one-time-code sign-in are all checked.
It does not apply to your decision API endpoints. Traffic from your own systems calling Decisimo for decisions is authenticated separately and is not affected by anything on this screen — restricting the portal will never interrupt live decisioning.
Working behind a proxy or VPN
The address Decisimo matches on is the one it sees as the origin of the request, taking Cloudflare and standard forwarding headers into account. If your organization routes traffic through a VPN or an egress gateway, the address you need to allow is that gateway's, not the address of an individual laptop. The your current address value at the top of the page always shows exactly what Decisimo sees, so it is the reliable thing to work from.