> ## Documentation Index > Fetch the complete documentation index at: https://nango.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Security > How Nango secures your API credentials and customer data. [Contact us](https://nango.dev/contact) if you have additional questions or if you require a security review for an Enterprise agreement. ## Compliance Nango is **SOC 2 Type II** certified, **GDPR** compliant, and **HIPAA** compliant. | Certification | Details | | - | - | | SOC 2 Type II | Annual audit covering security, availability, and confidentiality. [View report →](https://trust.nango.dev) | | GDPR | Data Processing Agreement (DPA) applies automatically to all cloud accounts. [View DPA →](https://nango.dev/terms#dpa) | | HIPAA | Business Associate Agreement (BAA) available with the [Growth add-on →](https://nango.dev/pricing) | We run regular penetration tests, a secure development lifecycle, incident response procedures, and continuous monitoring. The [Trust Center](https://trust.nango.dev) has our current policies and audit reports. ## Data storage, retention & deletion ### What Nango stores | Data | Includes | Encryption | Retention | | - | - | - | - | | Connections | Credentials, configuration, and metadata | See [Connections](#connections) | Until you delete the connection | | Integration credentials | Your OAuth client secrets and custom provider settings | **AES-256-GCM** | Until you delete the integration | | Nango API keys | Account and environment API keys | **AES-256-GCM** | Until rotated or deleted | | Environment variables | Values you set per environment | **AES-256-GCM** | Until you delete them | | Synced records | Record payloads written to the [records cache](https://nango.dev/docs/guides/functions/syncs/records-cache.md) by sync functions | **AES-256-GCM** | Payload **30 days**, record **60 days** | | Nango logs | Auth flows, function executions, proxy requests | Storage-level | **15 days** on Nango Cloud | | Audit trail | Control-plane changes | Storage-level | **1 year** by default | Everything is encrypted at rest at the storage layer. Rows marked **AES-256-GCM** carry an additional application-level layer: the value is encrypted before it is written, so it stays unreadable to anyone holding database access alone. Data is stored in a managed PostgreSQL database in AWS, network-isolated in a private subnet, with automated backups and point-in-time recovery. [BYOC](https://nango.dev/docs/guides/platform/self-hosting) deployments run in a cloud account you control, and all retention periods are configurable there. ### Encryption & key management **Key management** — Nango uses envelope encryption. A 256-bit data encryption key (DEK) performs the encryption and is itself stored only in wrapped form, encrypted under a key held in AWS KMS. **Algorithm details** — AES-256-GCM with a 256-bit key, a fresh 12-byte initialization vector per encryption, and a 16-byte authentication tag. GCM is authenticated, so a tampered value fails to decrypt rather than returning corrupted data. **In transit** — TLS 1.2+ on all traffic: your application to Nango, dashboard access, and Nango's requests to external APIs. ### Connections A connection holds everything Nango needs to call an external API on behalf of one of your customers: | Field | Contents | Encryption | | - | - | - | | Credentials | OAuth access and refresh tokens, API keys, other provider credentials | **AES-256-GCM** | | Connection configuration | OAuth scopes, authorization parameters, provider-specific settings | Storage-level | | Metadata | Customer-specific configuration you set through the API or SDK | Storage-level | Connections are retained until you delete them. Deletion runs in two stages: 1. **Soft delete (immediate)** — the connection becomes inaccessible, its syncs stop, and scheduled tasks are cancelled. 2. **Hard delete (31 days later)** — credentials, configuration, metadata, synced records, and job history are permanently removed. The window allows recovery from accidental deletion. > [!NOTE] > > Logs and audit trail entries age out on their own schedule. They are not removed when you delete a connection and remain until their retention window ends. ### Synced records > [!NOTE] > > Applies only if you use the [records cache](https://nango.dev/docs/guides/functions/syncs/records-cache.md). Nango prunes the [records cache](https://nango.dev/docs/guides/functions/syncs/records-cache.md) so customer data is not held indefinitely: * **Payload pruning after 30 days** without a record update. The record ID and payload hash remain, so change detection and your syncs keep working — but the data is no longer retrievable from the cache. * **Hard deletion after 60 days** without a sync execution. All records data associated with this sync is deleted, including delta-detection hashes. If you start the sync again it starts with an empty cache. Treat the cache as a delivery mechanism, not a data store: [fetch promptly and keep your own copy](https://nango.dev/docs/guides/functions/syncs/sync-efficiency.md#consume-changes-promptly). ### Nango logs [Nango logs](https://nango.dev/docs/guides/platform/observability.md) are the operational record of what ran in your account: auth flows, function executions, proxy requests. They are exportable via [OpenTelemetry](https://nango.dev/docs/guides/platform/observability.md#opentelemetry-export). For proxy requests and API calls made from your functions, Nango records the URL, method, status code, and headers — **never request or response bodies**, so customer data flowing through an API call is not written to the logs. Headers are redacted before they are stored: `Authorization` always, plus the connection's credentials and any other configured secret values. Credentials are also stripped from logged URLs. ### Audit trail The [audit trail](https://nango.dev/docs/guides/platform/audit-trail.md) records control-plane changes with actor, outcome, and originating IP: who created or deleted a connection, changed an integration, rotated an API key, or signed in. Entries are immutable and account-wide, exportable as CSV. ### Data purge requests For compliance requirements such as GDPR, contact Nango support to request an immediate data purge. We can expedite deletion when regulation requires it. ## Access control ### API authentication | Method | Grants access to | Lifetime | | - | - | - | | Environment API key | A single [environment](https://nango.dev/docs/guides/platform/environments.md): integrations, connections, functions, records, proxy | Long-lived, until rotated | | Account API key | Account-level APIs only — never environment data | Long-lived, until rotated | | Connect session token | One end user's auth flow, in one environment | 30 minutes | | Session cookie | Dashboard access | Session-based | See the [API keys reference](https://nango.dev/docs/reference/backend/http-api/api-keys.md) for key types, capabilities, scopes, and management. ### Environment isolation Each [environment](https://nango.dev/docs/guides/platform/environments.md) is fully isolated — separate credentials, connections, integration configurations, and API keys — so production data is never reachable from a development environment. ### Team roles (RBAC) Roles govern what each team member can see and change. | | **Full Access** | **Support** | **Contributor** | | - | - | - | - | | **Designed for** | Admins and production operators | Monitoring production without changing it | Developers working outside production | | Non-production: read, write, delete | ✓ | ✓ | ✓ | | Production: read non-sensitive data, trigger syncs | ✓ | ✓ | — | | Production: view API keys & credentials, write, delete | ✓ | — | — | | Manage team, billing, environments | ✓ | — | — | **Full Access** is the default for just-in-time provisioning via SSO, and every account needs at least one. Manual invitations let you pick the role. > [!NOTE] > > Roles apply to the dashboard only. They do not affect API authentication: any caller with a valid API key retains the access that key grants. ### Single sign-on (SSO) Nango Cloud uses [WorkOS](https://workos.com) for SAML SSO, supporting **Okta**, **Entra ID**, **OneLogin**, and 20+ other identity providers. | Plan | SSO support | | - | - | | Free / Pay-as-you-go | Google SSO only | | Growth add-on | SAML SSO | | Enterprise (Cloud) | SAML SSO + SCIM | | Enterprise (Self-hosted) | Not yet available (planned) | > [!NOTE] > > Nango has no SSO button on the login page — login must be initiated from your identity provider. ## Network access Allowlisting is only needed when **your customers' systems** restrict inbound traffic — private APIs behind a firewall, or systems that only accept approved IPs. Publicly accessible systems need no configuration. Nango makes outbound requests from these public IP addresses: * `52.34.139.153` * `54.69.127.183` * `44.247.133.183` * `52.26.211.56` > [!WARNING] > > These IPs may change as we scale. Allowlist all of them and review this page periodically; we will make reasonable efforts to announce breaking changes in advance. ## Vulnerability disclosure Security researchers can submit findings by following our [security policy](https://nango.dev/security). We appreciate responsible disclosures! ## Related guides * [API keys](https://nango.dev/docs/reference/backend/http-api/api-keys.md) - create scoped keys for production access. * [Auth guide](https://nango.dev/docs/guides/auth/auth-guide.md) - keep provider credentials out of your app. * [Token refreshing and validity](https://nango.dev/docs/guides/auth/token-refreshing.md) - handle revoked OAuth credentials. * [BYOC](https://nango.dev/docs/guides/platform/self-hosting) - run a dedicated Nango instance in your own cloud account. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.