Hand over n8n credentials and permissions

Definition. A credential connects a workflow to an application, for example through OAuth or an API key. The official credential creation guide explains setup and service-specific requirements. The connected application also determines the permissions actually granted.

Effective capabilities. Do not treat only the visible secret as sensitive. Someone who can run or modify a workflow using a privileged connection may be able to perform consequential actions without seeing the underlying key. Assess effective capabilities rather than merely checking whether a password field is masked.

Separate tasks. A read-only status report needs different permissions from a contact synchronisation that writes data. A workflow preparing message drafts does not automatically need authority to send them. Separate those tasks where the target system and operating model allow it.

The table separates the two access layers, n8n and the destination application, from the responsibility for renewing or replacing access:

Roles. n8n distinguishes instance roles from project roles. Available roles and administrative capabilities depend on the edition and plan. Check the current role overview and individual role permissions for your installation. Documentation was checked on 26 September 2026. Do not assume that a role labelled “Viewer” automatically provides the data separation your organisation requires.

Project boundary. A project is not a universal customer-isolation boundary for every connected system. For example, the API account might still be able to read every customer despite project separation in n8n. Record the result of that assessment in the access matrix.

Inventory fields. A credential inventory is a table containing:

• a meaningful name
• destination
• purpose
• environment
• account owner
• permitted actions
• renewal procedure
• dependent workflows

A name such as “CRM-Production-Contacts-Read” is more useful than “Account 2.” The table should not contain the secret itself.

Responsibilities. For every n8n connection, establish four responsibilities:

• who can create it
• who approves its permissions
• who can revoke it during an incident
• who checks dependent processes after a change

One person may hold several roles in a small team, but the responsibilities should still be explicit.

Personal accounts. Record whether access is tied to an individual employee. A workflow should not fail unexpectedly when an old employee's project account is deleted. Use organisation-appropriate accounts or application registrations according to the destination provider's rules.

Recovering ownership. Include the route for recovering ownership. A connection created during a project can become difficult to maintain if only the departing supplier knows which application registration or account supports it.

Scenario. The following is an illustrative design. A company hires an agency to maintain a CRM transfer. An internal sales administrator checks results, while IT controls application consent. The agency needs to change the workflow but does not need blanket access to every business application.

Planned setup. The planned setup uses customer-owned contracts and accounts, a documented CRM connection and separate test data. Before handover, IT reviews the actual API permission scope. The sales administrator receives the result access needed for their role, rather than automatically receiving production editing rights.

Negative test. Acceptance includes a negative test: the agency must not be able to edit resources outside its agreed project. The team also examines whether the workflow could perform an unintended destination operation. If the API only offers coarse permissions, record that limitation and apply suitable operating boundaries.

Why it matters. This exercise is more informative than a checklist saying “credentials encrypted.” Encryption protects stored material; it does not decide whether a person should be allowed to cause a privileged action.

Where keys do not belong. Do not place keys in description fields, normal spreadsheets, screenshots or sample payloads. Pay particular attention to HTTP headers, URLs and error messages. A token in a query parameter can appear in logs or copied links more readily than the team expects.

Credential fields and secret stores. Use credential fields and, where appropriate and supported by the edition, an external secret store. Ordinary configuration variables are not interchangeable with a designed secret-management mechanism. Review exports and saved execution data for sensitive material as well.

Allowed domains. For many credentials, n8n supports restricting allowed destination domains when used in the HTTP Request node. The credential documentation also explains that boundary: it applies to HTTP Request usage, not as a universal control over every dedicated node and network path.

Review copies. When sharing a workflow for review, provide invented sample values and a field description instead of live credentials. A reviewer normally needs to understand the connection type and scope, not possess the production secret.

Preparation. Start a planned renewal with the list of dependent workflows. Create or renew access using the provider's procedure. Test an authorised, low-consequence operation first, then validate the actual business process with a known case.

Transition. If the provider allows old and new keys to coexist, a limited transition period may help. If it does not, plan an explicit change window. Do not invent a universal rotation interval; consider supplier rules, data sensitivity and internal policy.

Revocation. After the change succeeds, revoke the old access and update the record. Do not leave unused keys active indefinitely because somebody might need them later. A documented recovery route should not depend on permanently valid obsolete credentials.

When an employee or supplier leaves, review their n8n account, projects, destination accounts, application consents, API keys and backup access. Removing an n8n user does not automatically revoke every permission in another system.

Then test that the required workflow still operates under its intended owner. Also verify that the removed user cannot initiate new actions. You can sign off access once you have shown who owns it, what it can actually do and that it can be revoked. A list of masked password fields is not sufficient evidence.

These pages cover the service overview and the related decisions for n8n credentials and permissions:

• n8n implementation and workflow operations
• Review n8n data flows and retention
• Plan Outlook and Microsoft 365 workflows in n8n
• Hand over an n8n project with tests, ownership and recovery

For a workflow review, start with the task, systems involved and typical exceptions. Discuss it with modernagents.