Fivetran Security: Protect connector credentials, roles and data flows

A Fivetran account holds working credentials for dozens of production databases and SaaS tools, plus write access to the warehouse they feed, so one over-privileged user or leaked API key can read or redirect an organisation's most sensitive data. Many Fivetran controls are customer-side settings, opt-in or plan-dependent: role-based access, SAML single sign-on, scoped API keys, private connectivity, Hybrid Deployment, data blocking and column hashing. This guide explains how identity works in Fivetran, which roles and keys to restrict, how to choose a connection method, how to keep sensitive columns out of the destination, and how to audit activity with the Fivetran Platform Connector. It is for data platform owners, analytics engineers and security reviewers. For the general pattern, see the ETL and ELT Pipeline Security Guide.

This is an independent guide from NHI Mgmt Group, based on Fivetran's public documentation as of November 2026. It is not sponsored or reviewed by Fivetran. Product features change, so confirm settings against Fivetran's current documentation.

Key takeaways

• Connector credentials are the real prize. Give each source a dedicated read-only database user or service account; Fivetran documents that databases and API sources need only read access, and destinations need CREATE on their own schema.
• Least privilege needs the right plan. Connection-level roles, custom roles and teams require the Enterprise or Business Critical plan; on other plans, keep Account Administrator to a very small group.
• Use scoped or service account API keys. A scoped key inherits its user's permissions; a service account key gives automation its own identity that survives staff changes.
• Prefer connections that avoid public exposure. PrivateLink or Private Service Connect, reverse SSH, the proxy agent or Hybrid Deployment avoid opening a database port to the internet.
• Block or hash before data lands. Data blocking keeps columns out of the destination, and SHA-256 column hashing with a per-destination salt keeps identifiers joinable without exposing them.

How identity and access work in Fivetran

Fivetran's access model has three scopes: the account, each destination (a warehouse or lake), and each connection (a pipeline from one source into a destination). People and teams are given roles at one or more of these scopes. Alongside them sit the non-human identities that actually move data.

Fivetran documents that troubleshooting data is obfuscated and kept for one week, and that in Hybrid Deployment credentials are stored in a key management system backed by a hardware security module run by its cloud provider, with an option to use your own encryption keys. Web traffic uses TLS 1.2 or later; database connections are SSL-encrypted by default and SaaS sources use HTTPS. Certificate verification supports hostname and root CA checks, and self-signed certificates can be validated by fingerprint. Security teams can review and revoke validated certificates and SSH host fingerprints under Validated Certificates and Keys in account settings, which is worth adding to periodic reviews.

Admin roles and privileged access

Fivetran's standard roles map to the three scopes. Current names are shown first with legacy names in brackets, because older accounts and documentation still use them.

Availability: Fivetran documents the Manage, Edit and View Connection roles, custom roles and teams as Enterprise or Business Critical plan features. Custom roles can change access scope and resource permissions, and creating one requires Account Administrator or the Roles:Manage permission. Teams let you grant roles to a group, including external contractors, rather than to individuals; Account Administrators and Team Managers can add members.

Why the roles matter: anyone who can edit a connection can change where it points or which tables it syncs, and anyone who can edit a destination can redirect data flows. Treat Manage Destination and Account Analyst as privileged, review them quarterly, and prefer destination-scoped or connection-scoped roles over account roles. Settings:Edit and Users:Manage are the permissions that change authentication and user access; keep them with administrators.

Authentication settings

• Authentication type restriction: account settings let you restrict login to Google OAuth or SAML, instead of the default "No restrictions". Restrict to SAML once single sign-on works so your identity provider's MFA and offboarding apply.
• SAML: Fivetran lists Microsoft Entra ID, Google Workspace, Okta, OneLogin, PingOne and RSA SecurID as supported identity providers. Responses must be signed with RSA-SHA256 and posted to the ACS URL; NameID must be the user's email. Users with several Fivetran accounts under the same email must still log in with username and password, which is a gap to manage for consultants and contractors.
• Just-in-time provisioning: the Enable user provisioning toggle creates users on first SAML login. A just-in-time user gets no permissions unless SCIM assigns them or an administrator grants a role, which is a safe default.
• Session timeout: on Enterprise and Business Critical plans the browser session timeout can be set from 15 minutes to 2 weeks (default 1 day). Shorten it for administrators' accounts where your policy requires.

See the SAML Security Guide for identity provider-side controls.

Integrations, API tokens and service accounts

REST API keys

The Fivetran REST API authenticates with an API key and secret sent as Basic credentials. Fivetran describes two kinds: a scoped key, tied to your user account, which inherits your role-based permissions; and a service account key, which uses a dedicated account for programmatic access. Choose the service account key for Terraform, orchestration and integrations, so automation does not inherit an administrator's rights or stop working when that person leaves. Store the key and secret in a secrets manager, never in repository files or orchestration variables, and rotate them on a schedule and after any staff change. For automation the account owns, system keys are the most governable option: only Account Administrators can manage them, each key carries a JSON permission file listing resource types (such as USER or CONNECTOR), access levels (such as READ) and optional resource ID filters, and the expiry can be set to 1 week, 1 month, 3 months, 6 months or never. Pick an expiry rather than "does not expire", scope the file to the resources the integration touches, and rotate with Actions, Rotate in the System Keys tab; the key and secret are shown once. See the API Key Management Guide.

Source and destination credentials

• Dedicated source users: create a database user or SaaS service account per Fivetran connection with read-only access to the schemas being synced. Fivetran documents that databases and API sources require READ-only access.
• Destination user: Fivetran needs CREATE so it can create and write its own schemas and tables. Do not reuse an administrator login; scope the user to Fivetran's schemas. See Service Accounts in Snowflake Guide for a warehouse-side example.
• Prefer key-based or OAuth authentication where the source or warehouse supports it, and rotate passwords that were set up manually.

Choosing a connection method

Fivetran documents six ways to reach a database. The direction of the connection decides what you must open in your firewall.

Data residency and processing location

Fivetran states that all connections configured in a destination run in that destination's designated location, and that data does not leave its region-specific servers during processing, with exceptions such as the email connector. The region is set per destination through the Data processing location setting, so data that must stay in more than one region needs a separate destination for each. Google Cloud is the default cloud provider, and choosing a specific cloud region requires the Business Critical plan. Fivetran says customer data is purged once written to the destination, usually within 8 hours, while connection credentials, OAuth tokens and metadata such as table and column names are kept for the life of the service. Where data must not leave your own network at all, use Hybrid Deployment.

Hybrid Deployment

Hybrid Deployment, an Enterprise or Business Critical plan feature, runs pipeline processing inside your own network through a Hybrid Deployment Agent on Kubernetes or on a Linux host with Docker or Podman, while Fivetran's cloud orchestrates. Only metadata (including MAR information) and logs are sent to Fivetran. The agent opens an outbound mutual TLS connection and Fivetran never initiates inbound connections, so no inbound firewall ports are needed and outbound traffic can be restricted to Fivetran's orchestration and API endpoints. Fivetran notes that the agent is not FIPS 140-2 certified, which matters for some regulated workloads. Treat the agent host or namespace as a privileged system: it handles source and destination data in clear text during syncs.

Data blocking and column hashing

• Data blocking: excludes tables and columns from syncs. Primary key columns cannot be blocked. Fivetran notes that blocked data still passes through its systems and may be stored temporarily during a sync, so blocking limits what lands in the destination but does not keep data away from Fivetran itself; use source-side views or grants if that is required.
• Column hashing: replaces values with SHA-256 hashes using a salt unique to each destination, so identical values remain joinable within that destination. Primary keys cannot be hashed, hashing is one-way, and it applies to future syncs only, so re-sync to hash historical data. Account Administrators can view the salt in the destination's Data Security Settings tab; protect that access, because the salt plus a list of candidate values (email addresses, phone numbers) lets someone reverse low-entropy identifiers by brute force.

See the Data Loss Prevention (DLP) Guide for classifying which columns to block or hash.

Logging and detection

The Fivetran Platform Connector syncs log events and account metadata into a schema in your destination, where you can query or forward them to a SIEM. The LOG and AUDIT_TRAIL tables hold point-in-time events; metadata tables include USER, TEAM, ROLE, ROLE_PERMISSION, RESOURCE_MEMBERSHIP, TEAM_MEMBERSHIP, CONNECTION and SOURCE_TABLE, with change-event tables for creations and modifications. For account-wide events such as role changes, team membership and account settings you need an account-level Platform Connector; a destination-level connector only sees its own destination.

Correlate with the source side: the dedicated Fivetran database user should only appear from Fivetran's documented IP addresses or your private connection, and only run read queries.

Metrics that show the controls are working:

• Number of Account Administrators (target: a small, named list).
• Percentage of connections using a dedicated read-only source user.
• Percentage of database connections not using a direct public connection.
• API keys belonging to service accounts rather than people, and their age since last rotation.
• Sensitive columns in the data inventory that are blocked or hashed (target 100% of those classified as not needed in clear).

Hardening baseline

1. Inventory: list users and their roles at each scope, teams, API keys and their owners, every connection with its method and source user, and every destination user. Turn on an account-level Fivetran Platform Connector first so the rest of the work is logged.
2. Fix identities: enable SAML, then restrict the authentication type to SAML; keep just-in-time users permissionless until a role is assigned; set a session timeout that matches your policy.
3. Reduce roles: cut Account Administrators to a small group, move people from account roles to destination or connection roles, and use teams and custom roles where your plan allows.
4. Replace personal API keys: create service account keys for automation, move them into a secrets manager and revoke the old personal keys.
5. Tighten source credentials: dedicated read-only users per connection, rotated, with network restriction to Fivetran's IPs or a private path. Test a sync after each change before revoking the old credential.
6. Move off direct public connections for sensitive databases, to PrivateLink, reverse SSH, the proxy agent or Hybrid Deployment.
7. Block and hash: block columns the destination does not need and hash identifiers needed only for joins; re-sync where historical data must be hashed.
8. Monitor: alerts from the table above and a quarterly access review using the Platform Connector's metadata tables.

Rollback: keep old credentials valid until the first successful sync with the new ones; role changes can be reverted by an administrator, and the Platform Connector's change events show what changed.

Small teams versus large estates: on plans without connection roles, custom roles or teams, the essentials are SAML, very few administrators, service account keys and dedicated read-only source users. Large estates on Enterprise or Business Critical plans should model access with teams and connection roles, manage configuration through the API with a service account key, and use Hybrid Deployment where data must stay inside their network.

Common misconfigurations

• Source credentials with write or admin rights: a connection set up with a DBA account gives anyone who compromises the pipeline full control of the source.
• Everyone an Account Administrator: common in accounts created by one team that grew; any administrator can redirect connections and see hashing salts.
• Automation on a personal scoped key: the key carries an administrator's rights and breaks, or lingers, when that person changes role.
• Database port open to the internet for a direct connection, beyond Fivetran's IP addresses. Restrict the port to Fivetran's IP addresses or use private connectivity, and require MFA and network allow lists on the warehouse.
• Treating blocking as keeping data from the vendor: blocked columns still pass through Fivetran during a sync; exclude them at the source if that matters.
• SSO enabled but not enforced: leaving the authentication type at "No restrictions" lets users bypass the identity provider.

Framework mapping

In ATT&CK terms, the main threats are misuse of valid cloud credentials (T1078.004 Cloud Accounts) and credentials left in configuration or code (T1552.001 Credentials In Files).

Practitioner checklist

• Authentication type restricted to SAML, with MFA enforced at the identity provider.
• Account Administrators limited to a small named group and reviewed quarterly.
• People hold destination or connection roles rather than account roles wherever the plan allows.
• Automation uses system keys with narrow JSON permissions and an expiry, or service account keys, stored in a secrets manager; no personal keys in pipelines.
• Every connection uses a dedicated read-only source user; the destination user is limited to Fivetran's schemas.
• Sensitive databases use PrivateLink, reverse SSH, the proxy agent or Hybrid Deployment, not a public port.
• Columns not needed downstream are blocked; join-only identifiers are hashed, and access to the salt is limited.
• An account-level Fivetran Platform Connector feeds audit events to the SIEM.
• Validated certificates and SSH host fingerprints reviewed, and stale ones revoked.

Standards and references

• Fivetran: Security
• Fivetran: Role-based access control
• Fivetran: Connection options
• Fivetran: Hybrid Deployment
• Fivetran: Privacy and data residency
• Fivetran: Using Fivetran in more than one region
• Fivetran: Data blocking and column hashing
• Fivetran: Single sign-on
• Fivetran: Fivetran Platform Connector
• Fivetran: System keys

Related NHI Mgmt Group resources: ETL and ELT Pipeline Security Guide · API Key Management Guide · SAML Security Guide · Secrets Management Guide