A PostgreSQL role property that allows an account to initiate streaming replication and related logical replication activity. It is intended for backup, standby, and change data capture workflows, but it also creates a sensitive entry point because replication commands can influence how the server loads output plugins and processes trusted code.
Expanded Definition
The replication attribute in PostgreSQL is a role property that grants the ability to start streaming replication and participate in logical replication workflows. In practice, it is the privilege that separates ordinary database access from operations that can read, ship, or apply database changes across nodes and pipelines.
Its boundary is important. The attribute is not the same as broad superuser access, but it is still highly sensitive because replication-oriented sessions can interact with replication slots, WAL access, and logical decoding paths. For that reason, it is usually treated as an infrastructure-level permission rather than a routine application privilege. Where organisations discuss it, the practical consensus is that it should be granted only to tightly owned service accounts with a clear backup, standby, or CDC purpose.
A common misunderstanding is to treat replication as a narrow availability feature only. In reality, it also affects what trusted code may be loaded or executed in the replication path, which makes role design and plugin trust part of the definition, not an afterthought.
Examples and Use Cases
Replication attributes appear in several operational patterns that depend on controlled access to database change streams. They are most visible when a role needs to move data rather than query it.
- A standby server connects to a primary instance and streams WAL so failover can occur with minimal data loss.
- A backup or archive process uses replication access to capture changes continuously instead of relying only on periodic exports.
- A change data capture pipeline reads logical changes and forwards them to downstream analytics or integration systems.
- An operator account is separated from application roles so replication can be managed without exposing normal application credentials to higher-risk database functions.
In environments using logical replication, the main tradeoff is convenience versus trust. The more broadly replication is exposed, the easier it becomes to integrate data movement, but the harder it is to constrain who can influence decoding, plugin use, and downstream data flow.
For teams formalising machine-account governance, the OWASP Non-Human Identity Top 10 is useful for thinking about how service-owned database access should be inventoried, bounded, and reviewed.
Security Implications
Mismanaging the replication attribute can turn a normal operational role into a high-value access path. If an account with this privilege is compromised, the attacker may gain access to database change streams, influence what data is replicated, or use replication-related features to support deeper persistence inside the data layer.
The main failure condition is excessive trust. A role created for one backup workflow is often reused for standby, CDC, and maintenance tasks, which expands blast radius and makes it harder to prove which system is actually responsible for each replication connection. If logical replication is enabled without careful plugin and role control, the server may also accept trusted code paths that were not intended for general use.
Observable symptoms include replication roles that outlive the systems they were created for, unclear ownership of replication slots, and service accounts that keep working long after a pipeline has changed. Those are strong indicators that the privilege has become persistent infrastructure access rather than a bounded operational permission.
Domain and Governance Relevance
Replication attribute governance sits at the intersection of database administration, machine identity control, and change pipeline assurance. It matters because the account is not just reading data; it is participating in a trusted delivery path that can move sensitive content across systems.
For NHI governance, the key question is ownership and lifecycle. Replication roles are often service accounts, not humans, so they need the same discipline applied to non-human identities: explicit business purpose, narrow scope, reviewable assignment, and removal when the pipeline is retired. That is especially important where one role supports multiple environments or tools, because trust can spread silently across a whole data movement chain.
In practical terms, the attribute should be interpreted as a control boundary. It affects which accounts can bridge production databases, backup platforms, replicas, and downstream consumers, so governance needs to track both the role itself and every system that depends on it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Replication roles are service-owned machine identities that need clear ownership and lifecycle tracking. |
| NHI-03 — Secrets and Credential Management | Replication access depends on credentials that can expose high-value database change paths. | |
| NHI-05 — Least Privilege and Access Scope | The attribute grants a sensitive database capability that should be narrowly scoped to required workflows. | |
| Recommendation — Inventory replication accounts and assign a named owner for each privileged database role. Rotate and protect replication credentials with the same rigor as other privileged machine secrets. Limit replication privileges to the smallest set of service accounts and workflows that truly need them. | ||
| CIS Controls v8 | 6 — Access Control Management | Replication accounts require disciplined provisioning, review, and deprovisioning. |
| 8 — Audit Log Management | Replication activity should be observable because it can move data and hide misuse. | |
| Recommendation — Review and remove replication access when the associated system, pipeline, or service is no longer needed. Log replication role usage and alert on unexpected sessions, slots, or plugin activity. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | A compromised replication role can be abused as trusted access to database replication functions. |
| Recommendation — Hunt for misuse of valid replication accounts as an initial or persistence access path. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
