Security & administration

This section documents the current Neo4j 2026.x calendar-versioned line — Neo4j moved from semantic to calendar versioning (YYYY.MM) in 2025, and the same line applies to the Graph Data Science library — as published at the Neo4j documentation, which is the reference these pages are written and verified against. No specific monthly patch is pinned. Some areas (Aura’s internal infrastructure, the Raft consensus implementation details, and the GDS Pregel API’s low-level internals) are linked, not documented in depth.

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production, as Neo4j iterates quickly.

This section’s bibliography lists the reference material consulted while preparing these pages.

Neo4j controls access in two layers: authentication decides who a connecting client is, and authorization — a role-based privilege system — decides what that identity may read, write or administer. This page covers both, plus the administration tasks (multi-database, backup/restore, transport encryption and auditing) that sit alongside them.

Authentication: native, LDAP and OIDC

A fresh installation ships one native user, neo4j, that must change its password on first login. Beyond that default, three authentication providers can be configured, and more than one can be enabled at once so different clients authenticate different ways (Auth & Authorization):

  • Native — users and their hashed passwords are stored inside Neo4j itself, managed with CREATE USER / ALTER USER / DROP USER.

  • LDAP — delegates authentication (and optionally role mapping) to a directory server, so credentials never live in Neo4j.

  • OIDC — delegates to an external OpenID Connect identity provider (Okta, Entra ID, Keycloak, …​) for single sign-on, mapping token claims to Neo4j roles.

// Native user management -- run against the system database.
CREATE USER alice SET PASSWORD 'a-temporary-value' CHANGE REQUIRED
  SET STATUS ACTIVE;

ALTER USER alice SET PASSWORD CHANGE NOT REQUIRED;

SHOW USERS YIELD user, roles, suspended;

DROP USER alice;

LDAP and OIDC are turned on in neo4j.conf (dbms.security.authentication_providers, dbms.security.authorization_providers); the directory/provider connection details and the claim-to-role mapping live alongside them. That configuration surface is large enough that it is only linked here, not reproduced — see Auth & Authorization for the full provider setup.

Role-based access control: built-in roles and privileges

Every user is granted one or more roles, and every role holds a set of privileges — each privilege names an action (MATCH, TRAVERSE, WRITE, CREATE INDEX, …​), a target (a database, a graph, a label, a relationship type, a property) and an effect (GRANT, DENY). A user’s effective access is the union of their roles' grants, minus any deny — deny always wins over grant, even from a different role held by the same user (Manage Privileges).

Five built-in roles ship out of the box (Built-in Roles):

Role Grants

admin

Full administrative privileges over the whole DBMS: users, roles, databases, privileges.

architect

admin minus user/role/privilege management — database and schema administration (indexes, constraints).

publisher

Read and write data, and start/stop the roles' assigned databases, but no schema changes.

editor

Read and write data only — no schema administration.

reader

Read-only access to the roles' assigned databases.

Custom roles compose the same privilege grammar. A typical pattern is a purpose-built role scoped to one label and one database:

// Create a role that may only read Movie nodes in the "moviesdb" database.
CREATE ROLE movieReader;

GRANT ACCESS ON DATABASE moviesdb TO movieReader;
GRANT MATCH {*} ON GRAPH moviesdb NODE Movie TO movieReader;

// Assign it to a user, then confirm what the role can do.
GRANT ROLE movieReader TO alice;
SHOW ROLE movieReader PRIVILEGES;

DENY overrides any broader GRANT — useful for carving an exception out of a wide role without rewriting it:

// alice keeps broad read access via another role, but is explicitly denied
// Salary, even if a future grant would otherwise expose it.
DENY READ {salary} ON GRAPH moviesdb NODE Employee TO movieReader;

Privileges are removed with the mirror-image REVOKE, which takes an optional GRANT or DENY to remove only that half:

REVOKE GRANT MATCH {*} ON GRAPH moviesdb NODE Movie FROM movieReader;
REVOKE DENY READ {salary} ON GRAPH moviesdb NODE Employee FROM movieReader;

SHOW PRIVILEGES audits the full picture across every role:

SHOW ALL PRIVILEGES YIELD role, graph, segment, action, access;

Compare this label/relationship-scoped grant model with MongoDB’s built-in and custom roles, which scope privileges to actions and resources (a database, a collection, or a cluster) rather than to graph labels and properties — the same GRANT/DENY-style idea, applied to a different data model.

Administration: multi-database, backup, encryption and auditing

This section is an overview only — the full treatment of multi-database topology, Fabric and clustering lives in Clustering & multi-database.

Multi-database. A single DBMS instance hosts several independent databases, each with its own data, schema and (via the privilege grammar above) its own access rules. SHOW DATABASES lists them; CREATE DATABASE / DROP DATABASE manage the set.

CREATE DATABASE moviesdb IF NOT EXISTS;
SHOW DATABASES YIELD name, currentStatus, role;
STOP DATABASE moviesdb;

Backup and restore. neo4j-admin database backup takes an online backup of a running database (Aura and self-managed clusters differ in exact availability); neo4j-admin database restore loads a backup set back into a stopped, empty database.

# https://neo4j.com/docs/operations-manual/current/backup-restore/
neo4j-admin database backup moviesdb --to-path=/backups/moviesdb

neo4j-admin database restore moviesdb --from-path=/backups/moviesdb/moviesdb --overwrite-destination=true

Bolt+TLS. Client-driver traffic can be encrypted independently of intra-cluster traffic. Enable it in neo4j.conf (server.bolt.tls_level=REQUIRED, plus a certificate under server.directories.certificates), then require it from the driver:

// Driver connection URI schemes select the TLS behaviour, not a Cypher statement:
// neo4j+s://   -- encrypted, full certificate trust
// neo4j+ssc:// -- encrypted, self-signed certificates accepted
// neo4j://     -- unencrypted (only for trusted internal networks)

Auditing. The security event log records authentication attempts and privilege-relevant administrative actions (user/role/privilege changes, database lifecycle commands) to a dedicated log file, configured under db.logs.security.* in neo4j.conf. It is a durable trail for who did what, separate from the regular query log.

Continue with Clustering & multi-database for causal clustering, Fabric and the full multi-database story.