pg_authid is a PostgreSQL system catalogue table that stores role authentication data and privilege flags. It holds role names, passwords as verifier data, and attributes such as superuser or login, and is restricted to database superusers because it exposes sensitive account controls.
What pg_authid contains
pg_authid is PostgreSQL’s internal role catalogue for authentication data and privilege flags. It is not a general metadata table, because it stores role names, password verifier material, and attributes such as superuser or login, making it sensitive by design.
Because the table sits at the centre of role control, it helps define who can authenticate and what that role can do once connected. That makes it a high-value target for both administrative misuse and post-compromise escalation.
Why pg_authid is tightly restricted
The table is restricted to database superusers because its contents reveal the most sensitive parts of account state. If an attacker or careless operator can read or alter those rows, they may gain durable access, weaken authentication controls, or identify privileged roles worth targeting.
The restriction also reflects a basic containment principle: role authentication data and privilege flags should be visible only to the smallest set of trusted administrators. NIST SP 800-53 Rev 5 Security and Privacy Controls provides the broader control model for protecting account data, limiting access, and auditing sensitive administrative actions.
How role data in pg_authid supports authentication
PostgreSQL does not use pg_authid as a user-facing login screen, but the catalogue still underpins authentication decisions. The stored verifier data and login-related flags influence whether a role can connect, while the surrounding server authentication settings determine how that role proves itself at connection time.
That separation matters operationally. A secure database posture depends on both the authentication mechanism in use and the integrity of the role catalogue that records who exists, which roles may log in, and which roles carry elevated authority. NIST SP 800-63 Digital Identity Guidelines is useful here as a reference point for strong authenticator handling and assurance thinking, even though PostgreSQL implements its own native authentication model.
Privilege flags, exposure, and administrative trust
Superuser and other role attributes in pg_authid are not cosmetic labels. They shape the trust boundary for the entire database, because a privileged role can bypass many normal permission checks, inspect security-sensitive objects, and in practice control the catalogue itself.
For that reason, pg_authid is best understood as part of the control plane for authorization as much as authentication. The same catalogue that records login capability also records whether a role should be treated as exceptionally trusted, which is why compromise of this table can become a full environment compromise.
Risk and Threat Considerations
pg_authid is dangerous when it becomes readable or writable outside tightly controlled superuser workflows, because the table exposes password verifier material and the flags that define highly trusted roles. That combination can support credential abuse, privilege escalation, and long-lived administrative compromise.
Failure mechanism: An attacker who obtains superuser-level SQL access, or who abuses a vulnerable administrative path, may read role verifier data, modify login or superuser attributes, or identify the highest-value accounts for follow-on compromise.
Impact: The result can be persistent access, weakened authentication assurance, lateral movement through privileged roles, and loss of trust in the database’s authorization boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | pg_authid exposes sensitive role control data that should be tightly restricted. |
| IA-5 — Authenticator Management | pg_authid stores role authentication verifier data tied to account control. | |
| AU-2 — Event Logging | Administrative access to role and privilege data needs auditability. | |
| Recommendation — Restrict catalogue access to the minimum set of trusted administrators. Protect verifier material and rotate it after any suspected exposure. Log and review changes to role attributes and sensitive catalogue access. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The term centers on authentication assurance and role-controlled account identity. |
| Recommendation — Use strong authenticator assurance and account governance for database administrative roles. | ||
Practitioner Guidance
Why practitioners should care: Treat pg_authid as a protected control object, not just another system table. Access to it should be limited to a very small administrative set, and any unexpected visibility into role verifiers or privilege flags should be treated as a security event.
What to watch for: Review any workflow that queries role metadata, changes login or privilege attributes, or touches superuser-adjacent accounts. If those actions are happening outside expected maintenance paths, they deserve immediate scrutiny.
Practitioner takeaway: If pg_authid is compromised, assume the database trust model may already be broken and investigate both account integrity and the path that allowed catalogue access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org