> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Configuring Integration Egress IP Addresses

> Allowlist Living Security's outbound IP addresses so your provider accepts our integration traffic.

Some providers restrict API access to an approved list of source IP addresses. When that restriction is enabled, your provider must be configured to accept traffic from Living Security's egress IP addresses, or the integration will be rejected at the network layer.

This page lists those addresses.

## There are two sets

Living Security reaches your provider over two different networks, and they serve different parts of the integration.

| Set                          | What leaves from it                                                                                                             | How many               | Varies by region? |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ---------------------- | ----------------- |
| **Integration sync traffic** | The scheduled API calls that import your data, and outbound playbook actions by default                                         | 4 addresses            | No                |
| **Platform traffic**         | Access-token requests for the integrations listed below, and outbound playbook actions on connections switched to direct egress | 2 addresses per region | **Yes**           |

Most integrations need only the sync set. A specific group needs **both**, permanently — see [Integrations that need both sets](#integrations-that-need-both-sets).

## Integration sync traffic

These four are the same for every Living Security region. Customers hosted in the EU use the same four as customers hosted in the US.

| IP address       | CIDR                |
| ---------------- | ------------------- |
| `52.34.139.153`  | `52.34.139.153/32`  |
| `54.69.127.183`  | `54.69.127.183/32`  |
| `44.247.133.183` | `44.247.133.183/32` |
| `52.26.211.56`   | `52.26.211.56/32`   |

For providers that accept a comma-separated list:

```text theme={null}
52.34.139.153/32, 54.69.127.183/32, 44.247.133.183/32, 52.26.211.56/32
```

## Platform traffic

Unlike the sync addresses, these **are** region-specific. Use only the pair for the region that hosts your organization. If you are not sure which region that is, ask your Customer Success Manager before you configure anything — allowlisting the wrong region's addresses leaves the integration failing in a way that looks like it has nothing to do with the allowlist.

| Region             | IP addresses                      | CIDR                                    |
| ------------------ | --------------------------------- | --------------------------------------- |
| **United States**  | `98.91.60.249`, `13.216.91.102`   | `98.91.60.249/32`, `13.216.91.102/32`   |
| **European Union** | `34.246.236.210`, `52.31.102.238` | `34.246.236.210/32`, `52.31.102.238/32` |

For providers that accept a comma-separated list:

```text theme={null}
United States: 98.91.60.249/32, 13.216.91.102/32
European Union: 34.246.236.210/32, 52.31.102.238/32
```

### Outbound playbook actions

By default, playbook actions that write back to a connected system route through the same path as your data syncs, so they leave from the **sync** addresses. Nothing extra is needed.

An administrator can switch an individual connection to **direct egress**, which moves that connection's actions to the platform addresses for your region. That setting exists for exactly this situation — a provider instance that restricts API access by source IP and needs a small, stable, Living Security-owned set to allowlist. A few providers always use direct egress because they cannot be proxied at all.

If you allowlist only the sync addresses and someone later switches a connection to direct egress, that connection's actions start failing while its syncs keep working.

## Integrations that need both sets

For most integrations, Living Security's integration service obtains and renews the access token itself, and everything reaches your provider from the sync addresses alone.

For the integrations below, that service cannot renew the token, so **the Living Security platform mints it directly** — once when you connect, and then continuously for as long as the connection is active. Those token requests leave from the platform addresses. The scheduled data syncs still leave from the sync addresses.

* [Auth0](/integrations/auth0)
* [Cofense Triage](/integrations/cofense-triage)
* Code42
* Cornerstone
* [CrowdStrike Falcon](/integrations/crowdstrike)
* [Microsoft Entra ID](/integrations/microsoft-entra-id) — including Microsoft Graph
* [OneLogin](/integrations/onelogin)
* Sophos Central
* Zscaler Client Connector

<Warning>
  **Both sets stay allowlisted for the life of the connection.** The platform addresses are not a setup-only requirement. Token renewal runs on a short cycle for as long as the integration is active, so removing them after a successful setup breaks the integration the next time the token expires.
</Warning>

If your provider's token endpoint and its data API are the same host — which is common — that one host has to accept both networks.

## Add every address in the sets you need

Traffic can leave from any address within a set, and which one is used for a given request is not fixed. Allowlisting a subset produces intermittent failures that are difficult to diagnose: some requests succeed, others fail, and the pattern looks unrelated to configuration.

This applies to the platform pair as much as the sync four. Each region runs two, and requests land on either.

<Warning>
  **These addresses are stable, but they are not permanent.** We work to keep them unchanged, and we change them only rarely and in exceptional circumstances — such as a change to our underlying infrastructure provider.

  Because a change is possible, bookmark this page. If an integration that previously worked begins failing, return here and confirm your allowlist matches the addresses above before opening a support ticket.
</Warning>

## Which integrations need this

An IP allowlist is a setting in *your* provider, not in Living Security. It applies only if your organization has enabled that restriction. If you have not enabled IP restrictions in the provider, no action is needed.

These providers commonly require it:

| Provider                                                            | Where the setting lives                                       |
| ------------------------------------------------------------------- | ------------------------------------------------------------- |
| [Abnormal Security](/integrations/catalog/abnormal-security-custom) | **IP Safelist** on the API token — mandatory                  |
| [KnowBe4](/integrations/catalog/knowbe4-custom)                     | **Allowed IP Addresses** on the Reporting API token           |
| [Netskope](/integrations/catalog/netskope-v2-custom)                | **Custom IP** list, if tenant IP allowlisting is enabled      |
| [Duo Admin](/integrations/catalog/duo-admin-custom)                 | **Networks for API Access** — optional                        |
| [Microsoft Entra ID](/integrations/microsoft-entra-id)              | **Named locations** referenced by a Conditional Access policy |

Other providers may offer a similar setting. Check the provider's page in the [Catalog](/integrations/overview) and the provider's own documentation.

## Symptoms of a missing or outdated allowlist

The two sets fail in opposite ways. Match the symptom to the set before changing anything.

### The connection succeeds, but data never arrives

This is the signature of a **missing sync address**.

Credentials are validated at connection time over a path that is often not subject to the same restriction, so the connection dialog in Living Security reports success. The failure appears later, when a scheduled sync runs and is blocked.

Look for:

* The connection shows as connected, but streams report no records.
* Sync runs fail with `401 Unauthorized` or `403 Forbidden`.
* An integration that worked for months begins failing with no change on your side.

### The connection cannot be created at all

This is the signature of a **missing platform address**, and it applies only to the integrations listed in [Integrations that need both sets](#integrations-that-need-both-sets).

Look for:

* Setup fails while obtaining an access token. No connection is created.
* The error reports that a host could not be reached, with no HTTP response behind it.
* The provider's own sign-in or Conditional Access logs show a blocked request from an address you have not allowlisted.

<Note>
  A connection that cannot be reached at all is **not** a credential problem. No authentication took place, so rotating the secret or regenerating the client credentials will not help. An unallowlisted source address is the most common cause, though a wrong host name, a wrong port, or a provider-side outage look the same from our side.
</Note>

A later change to your allowlist that removes the platform addresses shows up differently again: an integration that has been healthy for weeks stops within minutes, because the next token renewal is blocked.

## This does not cover phishing simulation delivery

The addresses on this page apply to **integration traffic** — the API calls Living Security makes to your connected systems to import data and to run playbook actions.

Allowlisting for **phishing simulation email delivery** is a separate configuration with its own addresses, sender domains, and downloadable allowlist packages. Complete it in **Settings → Phishing Simulation → Allowlisting**. See [Phishing Simulation settings](/features/settings/phishing-simulation) for that process.

Allowlisting the addresses on this page will not make simulated phishing email deliverable, and completing simulation allowlisting will not make a restricted provider API reachable. If you use both, configure both.

## Getting help

If integrations continue to fail after you have allowlisted the addresses for your region, contact your Customer Success Manager or [support@livingsecurity.com](mailto:support@livingsecurity.com). Include the provider name, the failing stream or the setup step that failed, and the timestamp so we can correlate it against our egress logs.