PostgreSQL security hardening guide for production

Why PostgreSQL security hardening is more than changing the password method

A PostgreSQL cluster that works can still fail a security review. Many clusters were built on defaults, a few shared application logins and network rules that were widened during an incident and never narrowed again. When the security or audit team asks for evidence, the question is rarely whether the database runs. It is whether each login, network path and privilege can be explained and tested. Hardening PostgreSQL covers that full set of controls: authentication, host-based access rules in pg_hba.conf, TLS for connections, least-privilege roles, row-level security where tables hold mixed-sensitivity data, audit logging, and patching on the minor release cadence. Authentication is the first place to look, but it is only one control. Moving stored passwords from MD5 to SCRAM is a change to the server's password_encryption setting and to the stored verifiers, and PostgreSQL 18 deprecated MD5 password authentication in favor of SCRAM. Before changing anything, confirm which roles still hold MD5 verifiers and which client drivers and connection pools can negotiate SCRAM. The authentication method in pg_hba.conf also needs review, because a permissive line placed above a stricter one takes effect first.

The work is harder than it looks for three reasons. First, applications often depend on old login methods or on a single shared role, and changing either can stop a service that nobody has documented. Second, roles accumulate over time. Grants added for a one-off migration, a retired reporting tool or a departed engineer remain until someone audits them against actual use. Third, settings that look correct in a configuration file may not match what the server loaded. A reload may not have happened, a value may be overridden in a per-role or per-database setting, or an include file may change the result. The reliable check is to query the running server's settings and its pg_hba rules, then compare them with the intended file.

Each of these issues creates a decision for the owning team. Decide which application roles will be split by function, who approves new grants, how long old methods will be tolerated, and which environments receive the change first. Plan a window for each change and a rollback path that restores the previous rule set. Also decide how audit logs will be retained and reviewed, because logs that nobody reads do not support a control claim.

DeployOpen plans and implements these controls inside your infrastructure, prepares configuration, role inventories and evidence for your compliance assessment, and documents what was changed and why. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so ask your assessor early which evidence they expect to sample, and agree that format before the hardening work starts.

Which PostgreSQL settings and features control access

Access to a PostgreSQL server is decided in several places at once: how passwords are stored, which connections are accepted, how traffic is encrypted, which roles hold which privileges, which rows a role can see, and what gets logged. A hardening project has to review each of these in the configuration files and on the running server, because the two can differ after a reload or a manual change.

Password hashing with password_encryption

The password_encryption parameter sets the hash method PostgreSQL uses when it stores a role password. Set it to scram-sha-256 so new passwords are stored as SCRAM verifiers. PostgreSQL 18 deprecated MD5 password authentication in favor of SCRAM, so MD5 hashes left from older roles are a finding to plan for. On the running server, run SHOW password_encryption, then check pg_authid for roles whose stored hash still begins with md5 and schedule password resets.

Host and hostssl rules in pg_hba.conf

The pg_hba.conf file decides which clients may connect, from which addresses, to which databases and with which authentication method. A host rule matches both plain and SSL connections, while a hostssl rule matches only SSL connections, so sensitive roles can be limited to hostssl. Review the file for broad address ranges and trust entries. On the running server, query pg_hba_file_rules, since the file on disk may not match the rules the server has loaded after a failed reload.

SSL and certificate settings in postgresql.conf

The ssl parameter turns on TLS for client connections. The ssl_cert_file, ssl_key_file and ssl_ca_file settings point the server at its certificate, its private key and the authority used to verify client certificates. Hardening also covers the key file permissions, the certificate expiry date and the minimum protocol version set by ssl_min_protocol_version. On the running server, run SHOW ssl, then query pg_stat_ssl to confirm that live sessions negotiate TLS and to see the protocol and cipher in use.

Roles, membership and object privileges

Roles control who can log in and what they inherit. Use group roles without LOGIN, grant them to people or applications, and check where INHERIT is enabled. GRANT sets privileges on existing objects, while ALTER DEFAULT PRIVILEGES controls the rights given to objects created later, and that is where privilege drift often starts. On the running server, query pg_roles and pg_auth_members for superuser accounts and membership chains, and check table privileges in information_schema to confirm the grants.

Row-level security policies

Row-level security limits which rows a role can read or change, using policies that PostgreSQL evaluates for each query. It suits multi-tenant tables and data that must be filtered by user or region. Table owners bypass policies unless FORCE ROW LEVEL SECURITY is set, so the relforcerowsecurity flag needs checking on every protected table. On the running server, query pg_class for relrowsecurity and relforcerowsecurity, then review pg_policies for each table that holds sensitive data.

Audit logging and the pgaudit option

Built-in logging parameters such as log_connections, log_disconnections and log_line_prefix record who connected, when and from where. The log_statement parameter controls how much SQL text is captured, which affects both audit value and log volume. pgaudit is an extension that records more detailed audit events, but its availability depends on the build you choose, so confirm it before designing around it. On the running server, run SHOW for each logging parameter, check pg_available_extensions for pgaudit, and confirm it appears in shared_preload_libraries.

Which authentication and TLS choices fit your environment

This table compares the authentication and TLS choices for a PostgreSQL cluster, with the situations where each one fits and the operational work it adds. Read each row as a decision: the first column names the choice, and the other columns show when it fits and what it costs your team to run. The main takeaway is that stricter settings are usually simple to switch on, but they recur as work in client drivers, certificate renewal and credential rotation.

Decision	When it fits	Operational cost
SCRAM-SHA-256 for password logins	New clusters and any client library that supports SCRAM	Stored MD5 hashes remain until each password is set again, so plan a rotation pass
Keep MD5 for legacy clients	Only for a named client that cannot speak SCRAM yet	A standing exception list to review, and PostgreSQL 18 deprecates MD5 password authentication
hostssl-only rules in pg_hba.conf	Any segment shared with other teams, vendors or cloud tenants	Server certificates to issue and renew, and client connection strings to update
Plaintext host rules on private networks	Isolated segments with no third-party access and documented network controls	Relies on network controls staying correct, so keep evidence of them for assessors
Client sslmode verify-ca	Clients trust your internal CA but connect by addresses that change	Lower setup effort, but the server name is not checked against the certificate
Client sslmode verify-full	Connections where host names matter, including load-balanced or pooled endpoints	Every endpoint name must appear in the certificate, so renewals follow hostname changes
TLS terminated at the PostgreSQL server	Direct connections where encryption must run end to end to the database	Each server needs its own certificate configuration and monitoring of expiry dates
TLS terminated at a proxy or pooler	Pooled or load-balanced access where a proxy already handles client connections	The proxy-to-server hop must still be encrypted, and both sides need audit evidence

How to harden a PostgreSQL cluster step by step

This sequence moves a PostgreSQL cluster from its current authentication and access setup to one where logins use SCRAM over TLS, privileges sit with group roles, tenant rows are filtered by policy and connections and schema changes are logged. Each step closes with a check that can be repeated, so every change can be reviewed before the next one begins.

Inventory roles, clients and access rules
Start by recording what the cluster already does. List every role in pg_roles with its login and superuser attributes, every client application with the PostgreSQL driver version it uses, and every line in pg_hba.conf, including its database, user and address columns. Query the pg_hba_file_rules view to confirm how the server parses the file. Drivers that lack SCRAM support will block later steps, so confirm each one with its maintainer. The step is done when the team has a written inventory that each application owner has checked.
Set SCRAM as the password hash method
Set password_encryption to scram-sha-256 with ALTER SYSTEM, then reload the configuration with pg_reload_conf(). Check pg_settings, where the value and its source should match the change. The setting only applies to passwords set after it takes effect, so existing MD5 hashes remain until each role's password is changed. Query pg_authid for rolpassword values that begin with md5 to list those roles. Some settings need a restart, so check the context column in pg_settings before assuming a reload is enough. The step is done when the MD5 list matches the inventory.
Migrate client logins and retire MD5 rules
Ask each application owner to reset the password of their login role so it is stored as SCRAM, or to move to a new role created for the purpose. Update connection strings and driver settings where needed, and test each application in a non-production environment first. The role owners reset their own passwords, and the team checks the result. When no MD5 roles remain, remove the md5 entries from pg_hba.conf and reload. Confirm in pg_hba_file_rules that no rule names md5, and re-query pg_authid to confirm no MD5 hashes remain.
Enable TLS and require hostssl
Install a server certificate and private key that the operating system account running PostgreSQL can read, and confirm the key file is protected. Set ssl to on and point ssl_cert_file and ssl_key_file at the two files. Make sure the certificate chain matches the trust store that clients use. Change the host lines in pg_hba.conf to hostssl, then connect from each client with sslmode set to verify-full. Check the context of each parameter in pg_settings to learn whether a reload or restart is needed. The step is done when a connection without TLS is refused by a hostssl rule.
Rewrite pg_hba.conf from specific to broad
Order the rules from the most specific match to the broadest. PostgreSQL reads pg_hba.conf from top to bottom and applies the first line that matches the connection, so a broad line placed above a narrow one hides the narrow one. Place each application's hostssl line, which names a database and role, above any subnet rule. Finish with an explicit reject line for all hosts so the intent is visible in the file. Reload, then check pg_hba_file_rules for parse errors and for the rule each test connection matches. Test one connection from each application and one from an address that should be refused.
Create group roles and minimize privileges
Create NOLOGIN group roles for each access level, such as read-only, writer and migration, and grant each group only the object privileges its applications need. Add login roles as members, and choose INHERIT or NOINHERIT for each one on purpose. On the public schema, revoke CREATE from PUBLIC where the applications do not need it, and review default privileges for new objects. Use the psql describe privileges command to inspect grants. Connect as each login role and attempt one action outside its grant. The step is done when each role can do its intended work and nothing beyond it.
Add row-level security to tenant tables
For each multi-tenant table, run ALTER TABLE with ENABLE ROW LEVEL SECURITY and write a policy that compares a tenant identifier to a session setting or a role attribute. Table owners and superusers bypass policies unless FORCE is set, and superusers always bypass them, so decide whether the table owner should be subject to the policy. Test each policy by connecting as a role from one tenant and comparing row counts with known data. Repeat with a role that should see no rows. The step is done when each tenant sees only its own rows and each expected denial appears.
Enable connection and DDL logging
Set log_connections and log_disconnections to on, and set log_statement to ddl so schema changes are recorded. Choose a log_line_prefix that includes the timestamp, process ID, user and database, so each entry can be tied to a login. Configure the log destination and rotation, and check each value and its source in pg_settings. Then make a successful connection, a failed login and a CREATE TABLE in a test database. Confirm each event appears in the log with the expected user and database. Retention and forwarding of the logs are decisions for your security team to record.

What drives PostgreSQL security hardening effort

This table lists the factors that move the time and cost of PostgreSQL security hardening, why each one matters and how to keep it under control. Count each driver in your own inventory before requesting a quote, because the scope of a fixed-scope engagement depends on these numbers. The largest levers are usually the role model and the number of clients still using legacy logins, since they touch every database and application.

Driver	Why it changes effort	How to keep it down
Number of databases and schemas	Each database needs its own privilege review, default privileges, extension checks and audit configuration.	Consolidate small databases where isolation allows, and apply one privilege template to every schema.
Roles and application clients	Every login role and client connection must be mapped, tested and documented against least privilege.	Standardize on group roles that carry privileges, and let application logins inherit them rather than hold direct grants.
Clients still using legacy logins	Clients on MD5 or trust-style access must be found, moved to SCRAM and retested one by one.	Set a migration deadline per application, inventory clients from server logs, and retire legacy entries from pg_hba.conf as each one moves.
Drivers and languages needing SCRAM checks	Each driver, library and language runtime must be confirmed to negotiate SCRAM before cutover.	Test one client per language in a shared test matrix, and record minimum driver versions in the runbook.
Tables needing row-level security	Each policy needs design, performance testing and negative tests showing that rows stay hidden from other roles.	Limit row-level security to tables that hold regulated or tenant data, and reuse a small set of policy patterns.
Multi-tenant isolation requirement	Tenant separation may need separate schemas, databases or policy enforcement, which changes the design and the test plan.	Settle the isolation model at the start, because changing it after policies are written multiplies rework.
Compliance scope and evidence requests	Auditors may ask for configuration baselines, access reviews, audit logs and change records, all of which must be produced and kept.	Agree the evidence list with the assessor before work begins, and collect it automatically from the configuration and logging pipeline.
Environments that must match	Development, test, staging and production each need the same authentication, TLS and role settings, and drift must be checked.	Write a single pg_hba.conf template and a single role-creation script, and deploy both to every environment from version control.
Teams that sign off on changes	Database, security, application and compliance owners may each need to approve authentication or privilege changes, which adds cycles.	Agree in advance which changes are standard and pre-approved, and limit formal sign-off to changes that alter access.

How hardening changes for single node, HA and air-gapped deployments

On a single node, hardening is concentrated on one host. That makes it easier to keep consistent, but every connection passes through one pg_hba.conf, one certificate set and one role catalog, so a single incorrect line affects every client.

Authentication file: Confirm that password logins use SCRAM and that no line still permits MD5 or trust. PostgreSQL 18 deprecates MD5 password authentication in favor of SCRAM, so older rule sets are worth reviewing before any upgrade.
Local access: Check the local socket and loopback rules. These are often left permissive from installation and are easy to overlook because the server is not exposed directly.
TLS: Confirm the server certificate, the key file permissions and whether hostssl rules are required for each remote network.
Role review: Confirm that application logins are not superusers and that object ownership is separated from the login used by the application.

Ask your team to map each pg_hba.conf line to the client network it serves, then test each rule with a login from that network before the change is accepted.

Secrets, certificates and audit trails to protect

Hardening PostgreSQL is only as strong as the material around the server: the private key that proves its identity, the passwords that open superuser access, the client credentials applications use, and the logs that record what happened. Each item needs an owner, a storage location and a permission model. The common goal is that people who administer the database cannot quietly change the record of what they did.

Server private key and file permissions

The server private key is what clients trust when they connect over TLS, so its theft lets an attacker impersonate the database. Confirm that the key file is readable only by the operating system account that runs PostgreSQL and by root, and that it is not copied into backups or shared repositories without encryption. Check the ownership and mode of the key and certificate files after every package upgrade or configuration management run, since these steps often reset them.

Certificate lifetimes and rotation

Server and client certificates expire, and an expired certificate usually causes an outage rather than a warning. Decide the validity period for each certificate, who renews it, and how the new file reaches the server without a full cluster rebuild. Confirm how your PostgreSQL version reloads certificate files and whether a restart is needed. Keep a record of issue dates and expiry dates for every certificate the database uses.

Superuser password and the postgres account

The database superuser and the postgres operating system account are both high-impact identities, and they are often forgotten during hardening. Restrict who can use the superuser role, store its password in a vault with break-glass access, and log every use. Limit operating system access for the postgres account to administrators who need it, and confirm that peer or local authentication is not left open to other users on the host.

Client credentials kept out of code

Application connection strings, passwords and certificate paths should live in a secrets manager or in environment settings managed by the platform, never in source repositories or container images. Give each application its own database role so a leaked credential has a narrow blast radius. Check that rotation can happen without redeploying code, and that old credentials stop working when they are retired.

Log files that hold sensitive statements

PostgreSQL logs can capture SQL text, including literal values, error messages and sometimes passwords in statements that were typed incorrectly. Decide which statements are logged and at what level, then restrict read access to the log directory and ship logs to a store with its own access controls. Confirm retention periods with your compliance owner, and check that log rotation does not leave readable copies in unexpected places.

Audit configuration and pgaudit settings

The audit trail is only useful if the settings that produce it are protected. Control who can change logging parameters, pgaudit settings and the audit role grants, and make those changes visible through configuration management or change tickets. Confirm that a superuser can be prevented from disabling auditing without another party noticing, and test this by attempting the change in a non-production environment. Forward audit records to a location the database administrators cannot edit.

How to prove the hardening holds and fails safely

The hardening holds only when tests show two things: the server is running the configuration you intended, and the paths you closed actually refuse access. Start with the configuration. Query the pg_hba_file_rules view, which shows how the server parsed each line of pg_hba.conf, including line numbers and any parse error, instead of trusting the file on disk. Then run SHOW for password_encryption, ssl, log_connections and the other settings in your baseline, and compare each value to a written record. A file edit that was never reloaded, or a setting overridden at the role or database level, shows up only in these checks.

Next, attempt the connections that must fail. Use psql with sslmode set explicitly, so a silent fallback cannot hide a problem. Confirm that a role whose password is still stored as MD5 is refused once the rules require scram-sha-256, that a plaintext connection to an address covered only by hostssl rules is rejected, and that a client from a network outside the allowed ranges cannot log in. Also connect as a role from one tenant and request rows that belong to another. Record the exact error text for each attempt. A test script that only confirms successful logins proves very little about the controls.

Row-level security needs its own test because it can fail quietly. Confirm in the catalog that row-level security is enabled on each protected table and that FORCE is set where the table owner must also be filtered. Then connect as each unauthorized role, including the application role rather than only an administrator, and count the visible rows. Superusers and roles with the BYPASSRLS attribute skip these policies, so confirm which roles hold those attributes and whether that is intended. Repeat the count after any policy change, since a missing predicate is easy to introduce.

Verify that the logs record what an investigator would need. Failed logins should appear in the server log with the role, the client address and the reason. Privilege-changing statements such as CREATE ROLE, ALTER ROLE, GRANT and REVOKE should be recorded at the level you selected. Standard logging settings do not capture every DDL statement in the form an auditor expects, so if you require statement-level audit trails, confirm with your vendor or packaging which audit extension is supported for your PostgreSQL version. Check that log files are shipped off the database host and that someone is named to review them.

Rehearse the rollback before you need it. Keep a dated copy of the previous pg_hba.conf, apply the new rules in staging, then restore the old file, reload the configuration and rerun the connection tests to confirm the earlier behavior returns. Time the steps and write the result down. Run the full suite in staging first, then in production with the same scripts. Keep the scripts, their outputs and the configuration snapshots under version control as evidence. These results support the work of your auditor or certification body, but they do not replace an independent assessment. DeployOpen prepares the controls and evidence, and independent auditors issue any audit report or attestation.

What to monitor, patch and document after hardening

This table lists the recurring security tasks that follow PostgreSQL hardening, what each one involves, and the evidence an assessor expects to see. Read it as a standing checklist: monitoring and access reviews repeat on a schedule, while patching follows PostgreSQL's release cadence and published support dates. The main takeaway is that hardening weakens over time without these routines, and the records you keep are what show the controls still work.

Item	What to do	Evidence an assessor expects
Failed logins and role changes	Review server logs for failed authentication and any new roles or grant changes. Set alerts for these events and agree the review cadence with your security team.	Log extracts, alert records and a dated review sign-off for each period
pg_hba.conf and role membership	Review pg_hba.conf rules and role membership on a fixed schedule and after staff or service account changes. Confirm that no MD5 rules remain.	Dated review record, diff against the approved baseline and removal tickets
Certificate expiry	Track expiry dates for server, client and proxy TLS certificates. Renew well before expiry and confirm that the new certificate is loaded after restart.	Certificate inventory with expiry dates and renewal change records
Minor releases	PostgreSQL ships minor releases at least every three months. Apply them by replacing executables and restarting, following your change process. Minor releases do not change the storage format.	Change records showing the version before and after, plus test results
Supported version list	Check the PostgreSQL versioning policy regularly. PostgreSQL 14 is supported to November 12, 2026 and PostgreSQL 18 to November 14, 2030. Plan major upgrades before end of support.	Version inventory mapped to end-of-support dates and a funded upgrade plan
PgBouncer and components in the path	Patch PgBouncer, TLS terminators, operating system packages and backup tools. PgBouncer 1.26.1 was released on October 14, 2026 with security fixes. Confirm the version in use.	Component inventory with versions, patch dates and vendor advisory references
Configuration baseline	Keep postgresql.conf, pg_hba.conf, TLS settings and service unit files in version control. Record each approved change with its reason and approver.	Versioned configuration repository with change history and approvals
Role model and exception register	Maintain the role hierarchy, the purpose of each login role and a register of approved deviations with owners and review dates.	Role model document, exception register and evidence of periodic review

What buyers ask before hiring help with PostgreSQL hardening

How much effort does PostgreSQL security hardening take?

Effort depends mostly on how many clusters, databases, client applications and roles are in scope, and how well those are documented today. Effort rises when many applications still authenticate with MD5 hashed passwords, when pg_hba.conf has many legacy exceptions, when certificates are managed by hand, when roles are shared, or when sensitive tables need row-level security. Effort falls when an inventory already exists and most clients already use SCRAM. Ask for a written scope that lists each cluster and its version, the control areas covered, and the testing each application needs. Ask the provider to show effort for discovery, configuration, application changes and verification as separate lines, and to mark which items recur, such as role reviews and patch cycles.

Can our own team harden PostgreSQL without an outside partner?

Often yes, if you have a DBA or platform engineer who has run PostgreSQL in production and an application owner who can test changes. The work requires skill in reading pg_hba.conf, managing TLS certificates, designing roles, testing authentication changes in a non-production environment and reading server logs. Teams most often get stuck on an unknown client inventory, shared service accounts, changes that touch many applications at once, and the lack of a staging environment that matches production. A partner adds capacity and an independent review of the configuration. Before deciding, check who can approve changes, who signs off application behavior, and whether you can roll back an authentication change within an agreed window.

What does a PostgreSQL hardening engagement need from our team?

The work needs administrative access to the database servers and their configuration files, read access to server logs, and an inventory of client applications, drivers, service accounts and batch jobs that connect to the database. It also needs change windows for reloads and restarts, a staging environment where authentication changes can be tested, and a named owner who signs off application behavior after testing. Certificate authority contacts are needed if TLS certificates will be issued or rotated. Most DeployOpen engagements are fixed scope, so these dependencies are written into the agreed scope before work starts, along with who is responsible for each one.

How long does PostgreSQL hardening take for a typical scope?

Duration is set by the written scope, not by a standard timeline. The main drivers are the number of clusters and replicas, the number of client applications that must be tested, whether any application needs a driver upgrade before MD5 can be removed, the change freeze calendar, and how long your approval cycles take. Schedule risk usually comes from application teams, not from database configuration. Ask for milestones that separate discovery, configuration changes, application testing and cutover, and ask which of those depend on your teams. Also ask how the schedule handles a failed test, since a failed authentication test often means a driver or application change.

Does removing MD5 password authentication break applications?

It can, if a client driver or application supports only MD5 password hashes. PostgreSQL 18 deprecated MD5 password authentication in favor of SCRAM, so plan the change rather than assume it is safe. Start by finding every pg_hba.conf rule that uses MD5 and every role whose stored password is still an MD5 hash. Then check that each client library and application version supports SCRAM. Passwords stored as MD5 hashes usually need to be reset under SCRAM before the MD5 rule is removed, so coordinate those resets with application owners. Test each application against a staging copy of the cluster, and confirm the exact behavior against the documentation for your PostgreSQL version.

Can row-level security be added without changing application code?

Often yes for simple cases, because row-level security is enforced by the database through policies. Confirm this table by table before committing to it. Applications must connect with roles that the policies apply to, since table owners bypass policies unless the table is set to force them, and the policy logic must match how each application identifies its users. If the application relies on session settings or on privileges of the table owner, behavior can change even though no code is edited. Run the existing test suite and representative queries as the application role, and check query plans, because policy predicates need supporting indexes on the filtered columns.

Does DeployOpen certify our PostgreSQL environment for compliance?

No. DeployOpen plans, implements, hardens, documents and prepares the systems, controls and evidence that a compliance assessment will review. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Before work starts, ask your auditor which evidence they expect for database controls, such as configuration baselines, access reviews, audit logs, change records and patch records. Those requests should be written into the scope so the evidence is produced during the work, not reconstructed afterward. Ask the auditor which framework and control identifiers apply to your organization, since requirements differ by sector and jurisdiction.

How DeployOpen scopes, hardens and hands over PostgreSQL security work

DeployOpen approaches PostgreSQL security hardening as fixed-scope work inside your own infrastructure. We agree the scope in writing, build and test controls such as SCRAM authentication, pg_hba.conf rules and TLS, then hand over documentation and runbooks your team can operate. Work starts from the PostgreSQL version you run, because support end dates determine how long a configuration receives security fixes.

How we scope

Inventory of clusters, versions, client applications and the authentication methods each one uses today.
Written scope listing which hardening controls apply, such as SCRAM, TLS, roles and auditing.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

Move password logins from MD5 to SCRAM, since PostgreSQL 18 deprecates MD5 password authentication.
Write pg_hba.conf rules that allow only named networks, databases, users and approved authentication methods.
Configure TLS for client connections, create least-privilege roles, and apply row-level security where data separation requires it.

How we hand over

Test every control against the running cluster, including rejected connections and denied role privileges.
Document the configuration, role model and audit settings so your team can review and reproduce them.
Provide a patching procedure for minor releases, which PostgreSQL issues at least once every three months.

How we support

Optional retainer covers ongoing hardening reviews, patch application and changes to roles and access rules.
Plan major upgrades before end-of-support dates, then recheck authentication and role settings on the new version.
Confirm with your auditors which evidence they expect; DeployOpen prepares evidence but does not issue assessment reports.

PostgreSQL security hardening