OpenMRS security hardening guide for patient records

What OpenMRS security hardening covers for patient records

Hardening an OpenMRS instance spans six areas: the gateway, the application server, the database, accounts and roles, backups, and module updates. If you are standing up or inheriting an instance that holds identifiable patient records, these are the decisions to settle before go-live. OpenMRS is a self-hosted Java application that runs on Tomcat or Jetty, with a relational database behind it (MySQL, MariaDB or PostgreSQL). All of this work sits inside your own cloud accounts, data centers or air-gapped networks. No vendor applies patches or changes default settings for you, so each control needs a named owner and a check on your own infrastructure.

Several services may be reachable at the same time, and each one is a path to records. The O3 Reference Application's Docker Compose setup, for example, runs a MariaDB database, the OpenMRS backend, an Nginx frontend that serves the 3.x modules, and an Nginx gateway, with an optional Certbot service for SSL certificates. Your deployment may also expose FHIR endpoints through the FHIR2 module. Before hardening, map every externally reachable address and port, the service behind each one, and the networks allowed to connect. Confirm whether the backend or database can be reached by any route other than the gateway, and decide how TLS certificates will be issued and renewed for each public name.

The software comes from a nonprofit community, and OpenMRS has no paid edition. OpenMRS Inc. provides the fiscal, legal and infrastructure foundation for the project, while volunteers and implementer organizations customize and deploy it. Unless you arrange ongoing support, no one is responsible for watching security notices for your instance. Assign a named owner to track releases of the Platform (latest 2.8.1) and the O3 Reference Application (latest 3.7.1), since the two are versioned separately. Modules also carry their own release cycles, so keep a written inventory of every module in your WAR file or distribution, with its version and the date you last reviewed it. Ask your implementer where they receive security notices for each module.

Some related work is covered elsewhere. Single sign-on through Keycloak or another OAuth 2.0 provider, and the upgrade path between Platform and O3 releases, have their own sibling topics, so this section treats them only as items on the hardening list. DeployOpen prepares controls, configuration and evidence for compliance assessments, but it does not issue audit reports or certifications. Independent auditors and certification bodies do that work. To scope hardening for your instance, gather a list of exposed endpoints, a description of the records held, your backup retention requirements, and the people who will hold administrator rights. Those inputs define the written scope and the quote that follows it.

Which OpenMRS components carry patient data and attack surface

An OpenMRS deployment is a set of separate parts, and each one holds or exposes something different. The cards below map where patient records live, which parts accept network traffic, and which hardening question each part raises before you decide how to configure it.

O3 Docker Compose: MariaDB database

The MariaDB container in the O3 Reference Application stack holds every patient record, encounter and user account, so it is the most important data store in the setup. Ask whether the database port is reachable from anywhere other than the backend container, where its data volume is stored, how it is encrypted at rest, and how backups are taken and protected. Confirm the database credentials are generated for your environment and not carried over from the sample configuration.

O3 Docker Compose: OpenMRS backend

The backend container runs the OpenMRS core and its modules, and it reads and writes patient data through the database. It also serves the REST API that the frontend and any integrations call. Check which API paths are exposed through the gateway, which module versions are included in the image, and how the container is configured to reach the database without exposing credentials in environment files or images.

O3 Docker Compose: Nginx frontend

The Nginx frontend serves the 3.x micro-frontend modules to clinician browsers. It holds no patient data itself, but it delivers the application code that runs in each user's session, so its build and content integrity matter. Confirm which module versions are bundled, how updates are rolled out, and whether security headers and content restrictions are set for the frontend responses.

O3 Docker Compose: Nginx gateway and Certbot

The Nginx gateway is the only container that should accept traffic from users and other networks, so it is where TLS is terminated and where requests are routed to the frontend and backend. The optional Certbot service issues and renews the SSL certificates it uses. Verify that plain HTTP is redirected, that only intended paths are proxied, that certificate private keys are readable only by the gateway, and that renewal failures are monitored.

Standalone package with embedded database

The Standalone package bundles the application server and an embedded database into one install, which keeps patient data on the same host as the application. That combines the database and application attack surface on a single machine. Ask who can log in to the host, whether the embedded database accepts connections beyond localhost, where backups are written, and how the host operating system and Java runtime are patched.

WAR file on Tomcat with existing MySQL

The WAR file deployment places the OpenMRS application on an Apache Tomcat server that connects to a MySQL database you already run. Patient data sits in a database that may be managed by a separate team and shared with other systems. Check the Tomcat manager and administrative interfaces are not exposed, that the database account used by OpenMRS has only the privileges it needs, and that the connection between Tomcat and MySQL is protected.

Core Java application on Tomcat, Jetty, or database engine

The core Java application runs on Tomcat or Jetty and supports MySQL, MariaDB and PostgreSQL. The choice of servlet container and database engine sets which patches, configuration options and hardening guides apply to your deployment. Confirm the versions of the servlet container, Java runtime and database engine are supported by the OpenMRS release you run, and record which settings you have changed from the defaults.

FHIR2 module REST endpoints

The FHIR2 module exposes the FHIR REST API for OpenMRS, which returns patient, encounter and observation resources to any client that can authenticate. It is often the first API that external systems reach, so it widens the exposure of patient data beyond the user interface. List which FHIR resources are enabled, confirm which roles can read or write each one, and decide whether the endpoints should be reachable from outside your internal network at all.

SMART on FHIR module launch endpoints

The SMART on FHIR module lets third-party apps launch from OpenMRS and request scoped access to patient data through an OAuth 2.0 authorization server, which Keycloak is by default. Each registered app receives access tokens that expand what data leaves the system, so the risk sits in client registration, scope grants and token lifetimes. Review which apps are registered, which scopes each can request, and how revocation and token expiry are handled.

Decisions that shape OpenMRS security hardening

This table compares the architecture decisions that change how much hardening work an OpenMRS deployment needs, and what each choice costs to run. Read each row for when an option fits and what it commits your team to after go-live. The main takeaway is that the gateway, deployment form and login model fix most of the ongoing work, so settle them before configuration starts.

Decision	Option and when it fits	Operational cost to plan for
TLS termination	Bundled Nginx gateway fits sites where one team owns the whole stack and has no enterprise load balancer to terminate on.	Your team owns certificate issuance, renewal and cipher settings inside the stack, and must check the gateway configuration after each upgrade.
TLS termination	External load balancer fits organizations that already centralize TLS, certificate inventory and web application firewall rules.	The load balancer team owns certificates and policy, but you must confirm which headers and client addresses reach the backend so audit logs stay accurate.
Certificate source	Certbot-issued certificates fit internet-reachable sites with a public domain and staff who can keep the renewal job running.	Renewal depends on the Certbot service staying healthy and on inbound validation paths remaining open, so failed renewals need an alert and an owner.
Certificate source	Internal certificate authority fits networks that are closed to the public internet or that already run a corporate certificate service.	Clinics and devices must trust the internal root, and the CA team must handle renewal, revocation and distribution of the root to every site.
Deployment form	Standalone package fits small or single-site installs that need the fewest moving parts and an embedded database.	Hardening is largely host-level work, so your team owns operating system patching, database placement and backup scheduling directly.
Deployment form	WAR on Tomcat fits teams with existing Tomcat operations and an existing MySQL database to reuse.	You own the servlet container, its patch cycle and its TLS settings, and the Java runtime version must match what each OpenMRS release supports.
Deployment form	O3 container stack fits teams comfortable with Docker or equivalent orchestration and the O3 frontend, which the Reference Application ships as four services.	Image updates, container hardening and secrets handling become recurring tasks, and staff need container and Nginx skills to review changes.
Database engine	MariaDB or MySQL fits sites reusing existing MySQL-family operations skills or the MariaDB service in the O3 Compose setup.	Your team patches the database, manages user grants and encryption settings, and confirms the engine version against the OpenMRS release notes.
Database engine	PostgreSQL fits organizations standardized on PostgreSQL, where that skill base and backup tooling already exist.	Confirm the module set and distribution you plan to run supports this engine, since the chosen database shapes migrations and support options.
Login model	Local OpenMRS accounts fit small, closed deployments with few users and no central identity directory.	Your team manages account lifecycle, password policy, leavers and role reviews by hand, which adds recurring access-review evidence work.
Login model	Delegated login through the OAuth2 Login module fits sites with an OAuth 2.0 identity provider such as Keycloak and a need for central offboarding.	You own role mapping from identity provider claims, JWT service account keys and the identity provider's patching, and must test the mapping after every change.
FHIR endpoints for external apps	Keeping FHIR2 internal fits sites with no third-party apps or integrations that need patient-level API access.	The FHIR surface still needs authentication review and logging, but the exposure and vendor review burden stays low.
FHIR endpoints for external apps	Exposing FHIR2 and SMART on FHIR fits programs that need approved external apps to launch against patient records.	You must maintain app registration, scope review, token lifetimes and per-app audit logs, and confirm which resources each app can read.

How to sequence OpenMRS security hardening steps

This sequence takes an OpenMRS deployment from an unknown exposure surface to a documented, tested and patchable state, with each step closed by a check that the next step depends on. It is written for the team that owns the patient record system and the partner doing the work.

Inventory exposed services and patient data stores
Start by listing every port, hostname and service the deployment exposes, including the gateway, the application server, the database, any Certbot or certificate helper, and any management or manager interface on the application server. Record where patient data lives: the primary database, backups, logs, exported files, and any search or reporting copies. Assign an owner to each item. The step is done when the inventory matches what a network scan from outside and from inside the hosting network actually finds, and every unexpected listener has an explanation or has been closed.
Terminate TLS at the gateway with valid certificates
Configure the gateway to serve only encrypted connections with certificates issued by a trusted authority for the correct hostnames, and renew them automatically. Confirm that the application server and database do not accept plaintext requests from anywhere except the gateway's internal path, and that redirects from HTTP do not expose session data. Check the certificate chain and expiry from a clean client, then confirm that no route to the backend bypasses the gateway. The output is a short test record showing each hostname, protocol and certificate, plus a failed plaintext attempt for each backend port.
Remove default and installation-time credentials
Build a list of every account and password created during installation, including the application administrator, database users, sample or demo users, and any service accounts in the distribution in use. Confirm each against the documentation for the specific release you run, since defaults differ between the Platform and the O3 Reference Application. Disable or delete what is not needed and rotate the rest into a managed secret store. The step is complete when a login attempt with each known default fails and an administrator can list every remaining account with its owner and purpose.
Separate database accounts and restrict network access
Create a dedicated database account for the application with only the grants it needs to read and write its schema, and a separate account for migrations or administration that is not used at runtime. Restrict the database listener so that only the application host can connect, using host-based grants and network rules. Remove anonymous and unused accounts. Verify by connecting from the application host with the runtime account, then attempting the same operations with the admin account from the application host and from another host. The output is a grant review that shows least privilege and a connection test from an unauthorized host that fails.
Harden the application server management interfaces
On Tomcat or Jetty, disable or remove the manager and management applications unless they are required, restrict any remaining management endpoints to administrative networks, and change default administrative credentials if they exist. Turn off directory listings, remove sample applications and default error pages that reveal version details, and confirm the server's shutdown port is not reachable from outside the host. Check each change by requesting the management paths from an external client and from an administrative network, and record the response codes. The step closes when only the expected application paths answer externally.
Review roles and privileges in the administration screens
Export the list of users, roles and privileges from the OpenMRS administration screens and compare each against a documented job function. Remove privileges granted for convenience during implementation, separate system administration from clinical access, and confirm that accounts created by any external login integration receive the roles you intend, not broader ones. Have a clinical or operational lead sign off on the matrix. The check is a signed privilege matrix and a test login for at least one account per role showing that it can do its job and nothing outside it.
Manage secrets for passwords, certificates and tokens
Identify every secret the deployment depends on: database passwords, TLS private keys, any OAuth client secrets, and any JWT service account keys used by integrations. Move them out of configuration files stored in source control or shared drives into a secret store or protected host location with restricted read access. Set a rotation procedure and record who can rotate each secret. Confirm the application still starts and connects after the move, then scan the configuration repository and file shares for remaining plaintext values. The output is an inventory of secrets with locations, owners and rotation steps.
Encrypt and test backups of database and configuration
Set up scheduled backups of the database and the configuration needed to rebuild the application, including the gateway configuration and module list. Encrypt backups at rest and store the decryption keys separately from the backups. Restrict access to backup storage to the operators who need it, and log restores. Then perform a restore into an isolated environment and confirm that the application starts, that a known test record is present, and that logins work with the restored accounts. Record the time and steps of the restore so the procedure can be repeated.
Pin module versions and document the patch path
List every installed module with its version, source and the platform version it was built for, and pin each one in the build so that a rebuild produces the same set. Subscribe the team to security notices for the Platform, the O3 Reference Application and each module in use, and write down who reviews them, how a fix is tested in a staging copy, and how it is deployed and rolled back. Confirm the process once by applying a minor update in staging. The step is complete when the module inventory, pinned build and patch procedure are stored with the system documentation and a staging update has been recorded.

What drives OpenMRS security hardening effort and cost

This table lists the factors that move the effort and cost of hardening an OpenMRS deployment, how each one changes the work, and how to keep it contained. Read it as a checklist to bring into a scoping conversation, then ask the partner to price each driver separately in the written scope. Most of the cost sits in one-time assessment and configuration, while patching, certificate renewal and access reviews recur for as long as the system runs.

Driver	Why it changes effort or cost	How to keep it down
Number of sites and hosts	Each site or host adds configuration, host baselines, network paths and evidence to collect. Hosts across several clinics multiply the same checks.	Use one standard build for gateway, application and database hosts, and limit the number of hosting locations in the first phase.
Exposed services and endpoints	Every externally reachable service, including the gateway, FHIR API and any admin interface, needs TLS, access rules and testing.	Publish only the endpoints users need through one gateway, and close or restrict administrative paths by default.
Custom or community modules	Each module adds code to review, version pinning, patch tracking and possibly testing after platform upgrades.	Keep the module list short, prefer maintained modules, and record the version and owner of each one before hardening starts.
Customized privileges and roles	Custom roles and privileges must be mapped, reviewed and tested for least privilege. Ad hoc role changes over time make this slower.	Agree one reviewed role model before configuration, and route all role changes through a documented request and approval step.
External FHIR or SMART app connections	Apps launched by external parties add token scopes, client registration, data-sharing decisions and monitoring of API access.	Limit connected apps to a reviewed list, use a single authorization server, and document which scopes each app needs.
Hosting model	Client cloud, client data center and air-gapped networks each need different network controls, update paths and evidence sources. Air-gapped sites need offline patch and certificate processes.	Confirm the hosting model at scoping. Reuse the same hardening baseline across environments and document only the differences.
Compliance framework to evidence against	The framework sets the controls, evidence format and sampling your assessor expects. Broader frameworks add more control mapping and more evidence to produce.	Ask the assessor early which framework and control set applies, and build the evidence map once for all parallel requirements.
Existing team skills in Linux, TLS and databases	Teams without experience in these areas need more knowledge transfer, and more of the configuration and verification work falls to the partner.	Name internal owners for host administration, certificate management and database backups, and schedule them to shadow the configuration work.
Recurring operations	Patching, certificate renewal, access reviews and backup restore tests repeat on a schedule and need named owners and records each time.	Automate certificate renewal and patch checks where possible, and ask for the recurring tasks to be listed with owners in the quote.

Access control, secrets and privileges to lock down

Most OpenMRS exposure comes from accounts, credentials and interfaces that were left at their defaults or widened for convenience. The six controls below cover who can do what inside the application, who can reach the database and APIs, how secrets are stored, and what gets recorded. Each card gives the reason for the control and what to verify before go-live.

Design roles around each job

OpenMRS controls what each user can see and change through roles and privileges, so clinical, registration and administrative staff should each hold only the set their work requires. Start from the actual job list at each site, map it to the roles in your chosen release, and create custom roles where the defaults grant more than a post needs. Verify by logging in with a test account for each job and confirming that record screens, data entry and administration menus match the role on paper. Review assignments whenever staff change posts.

Separate application and database administrators

People who manage OpenMRS user accounts and global settings should not also hold owner or root rights on the MariaDB, MySQL or PostgreSQL server, because one compromised login would then reach both the application and the stored records. Give the application its own database account with only the privileges it needs to run and to apply planned migrations, and keep administrative database access with a small, named group. Verify by connecting with the application account and attempting a schema change outside an upgrade window, which should be refused.

Keep secrets out of code and images

Database credentials, Java keystore passwords and OAuth client secrets unlock patient data, so they should be injected at runtime from a secrets store or protected host configuration and kept out of source control, the WAR file and container images. Environment files in the O3 Docker Compose setup are a common place for values to be committed by accident. Verify by scanning the repository and built images for credential patterns, and test the rotation procedure for each secret before go-live.

Restrict FHIR API and SMART app access

The FHIR2 module exposes the FHIR REST API, and the SMART on FHIR module lets registered applications launch against it, so both extend the attack surface beyond the user interface. Allow only the clients your team has reviewed, limit each client's scopes to the resources it needs, and disable or restrict any resource types your deployment does not use. Verify by calling the endpoints with an unregistered client and with a registered client that requests extra scopes, and confirm that both are refused.

Short-lived keys for JWT service accounts

When the OAuth2 Login module authenticates services with JWT service accounts, the signing key becomes a standing credential that can act inside OpenMRS. Set short token lifetimes, rotate the key pair on a fixed schedule, and record a named owner for each service account. Verify that an expired or revoked token is refused and that a rotated key no longer works. The sign-in configuration itself is covered in the SSO topic.

Audit logins and record access

Audit records show who signed in and who opened, changed or administered a patient record, which is the evidence needed after a suspected misuse. Do not assume the release logs every event you need. Confirm which login attempts, record views, edits and administrative changes your chosen release writes to logs or an audit trail, where those entries are stored, how long they are kept, and whether application administrators can alter them.

How OpenMRS security hardening changes by deployment model

On a single node, the web server, the OpenMRS application and the database usually share one host. That concentration makes the host the single place where TLS is terminated, certificates are stored, the database is reached and backups are taken, so each control is simpler to enforce but also has no second copy if the host fails.

TLS termination: One host terminates TLS, either at a reverse proxy or at the servlet container connector in front of the OpenMRS application. Redirect or block plain HTTP to patient data paths.
Certificate distribution: One certificate set lives on one host with one renewal job. Limit read access to the private key to the service account that runs the web server.
Database exposure: Bind the database to the loopback interface or a local socket, and do not publish its port on any external interface.
Backups: Write backups to a location outside the host, encrypted before they leave it. A host failure removes the application and its data together unless a copy exists elsewhere.
Patch delivery: Operating system, Java runtime, Tomcat, the OpenMRS WAR and modules are all updated on the same host. Keep a copy of the previous WAR and modules directory so you can roll back.

Confirm with your implementer which TLS endpoint and database port the release you run uses by default, and test a restore on a separate host before go-live.

How to test that OpenMRS security hardening holds and fails safely

Each hardening control needs a test with a stated pass condition, and the test should run against the running system. Use the configuration files as a starting point only. Begin with network reachability. From a workstation on a user network, only the gateway address and port should answer. From the application host, the database should accept connections, and from every other host, including user networks and the gateway itself, the database port should be refused. Record the source host, target, time and result for each attempt. Repeat these checks after every change to firewall rules, security groups or container networking, because those changes often go unnoticed in a deployment that still appears to work.

Check the TLS configuration at the gateway with a scanner that reports the full certificate chain, the expiry date, the protocol versions accepted and the cipher suites offered. Confirm that the chain is complete and trusted by the devices that will connect, and that only the protocol versions your security policy approves are accepted. Then request the plaintext HTTP address and confirm that the response is either a redirect to HTTPS or a refusal. Cover API paths as well as the web interface. If you enable the FHIR2 module, test its endpoints directly, because a gateway rule written for the web pages may not cover every route. If you use the Certbot service from the O3 reference stack, test renewal in the copy as well as the first issue, since an expired certificate stops every user at the same moment.

Test accounts and roles by trying to act as the wrong person. In a test copy, attempt to log in with the credentials that the installation ships with or that its documentation describes, and confirm that each one is disabled or has been rotated. Then create a test user with a low-privilege role and try to reach administration screens, system settings, user management and the bulk record export. Test both through the interface and by calling the underlying URLs or API endpoints directly, because a hidden menu item does not block the function behind it. Repeat the test for each role your implementation defines and for each module that adds its own endpoints. Keep the test accounts out of production and remove them when the test window closes.

Two tests show whether the controls fail safely. The first is a restore. Take a recent backup, restore it into an isolated environment with no route to production, and compare record counts for patients, encounters and observations against the source at the same point in time. Confirm that the users you expect can log in, and that the restored copy does not reuse production passwords, keys or service account secrets. The second is a failure test. Stop the database, then the gateway, one at a time. Check that no response contains patient data, that error pages do not reveal stack traces or connection strings, and that no administration path is left open by a partly applied configuration. Review the application and gateway logs afterward for the failure event and for any request that succeeded when it should have been refused.

Treat the external vulnerability scan and the application security test as two separate steps with separate scopes. The vulnerability scan examines exposed services and known weaknesses in the platform version and its operating system packages from outside the network boundary. The application security test examines how OpenMRS and its modules handle authentication, authorization, input validation and sessions, and it usually needs authenticated access with several roles. Agree the scope, testing windows and any production restrictions in writing before either begins, and confirm which accounts and environments the tester will use. Findings and retest results are evidence you can give your auditor and governance board. They record what was tested on a given date. They are not a certification, and an independent auditor or certification body decides what, if anything, they attest to.

Monitoring, backups and module patching after hardening

Hardening holds only if someone keeps checking it. The cards below cover the recurring controls that protect an OpenMRS deployment after go-live: watching certificates and logs, reviewing access, backing up the database and configuration, and keeping modules and release levels current. Document an owner and a review frequency for each one so that every control has a named person behind it.

Certificate expiry and gateway health

Monitor the expiry date of every TLS certificate at the gateway and alert well before it lapses, because an expired certificate stops clinicians from reaching the record system. Where the O3 Docker Compose setup is used, confirm who owns the optional Certbot renewal and whether renewal failures reach a person. Also check gateway health and error rates so that a failing proxy is noticed before users report it.

Authentication failure and privileged action logs

Review authentication failures and privileged actions in both the OpenMRS application logs and the database logs on a set schedule. Look for repeated failed logins, logins outside clinic hours, changes to user roles and privilege grants, and direct database changes made outside the application. Agree in advance who receives alerts, how quickly they respond, and where log copies are kept.

Scheduled access reviews and leavers

Review user accounts and their roles on a fixed schedule, and confirm that each active account still matches a current job at its site. Pay particular attention to staff who move between clinics, contractors whose engagements have ended, and accounts shared between people. Record each review and its outcome so that an auditor or the client can trace who approved which access.

Encrypted backups with tested restores

Back up the database and the configuration files on a schedule, encrypt the backups, and keep at least one copy offsite from the primary environment. A backup counts only after a restore has been performed and the restored system has been checked against the source. Record the restore date, the person who ran it and the time it took, and repeat the test on a set frequency.

Module inventory and staged patching

Maintain an inventory of every installed module with its version, source and a named owner who answers for it. Apply patches on a fixed schedule, and test each change in a staging copy of the production database and configuration before it reaches clinics. Keep the previous module build available so that a failed patch can be reversed quickly.

Release notices for platform and O3

Track release notices for the OpenMRS Platform and the O3 Reference Application, and name the person who reads them, decides whether a release affects the deployment and applies any security fix. Upgrade procedures and version migrations belong to the upgrades topic, so this card covers only the intake, triage and ownership of notices. Confirm the notice channels and the review frequency with the client's own team.

How much work is OpenMRS security hardening and what do we need to supply?

How long does OpenMRS security hardening take?

Duration depends on the size and state of the deployment, and no single figure fits every OpenMRS installation. The main drivers are the number of hosts, sites and gateways in scope, whether the system runs the O3 Reference Application container stack or a Tomcat WAR with an existing MySQL, MariaDB or PostgreSQL database, how many custom or third-party modules need patch review, how much TLS and certificate work is required, and how quickly your team can answer questions about roles and privileges. Ask for the timeline in the written scope, which lists deliverables and the assumptions behind the schedule. Any quote should state which of these drivers it assumes.

Can our internal team harden OpenMRS without a partner?

Yes, a capable internal team can do much of this work if it already operates the relevant stack. You need Linux administration to harden hosts and the gateway, TLS skills to manage certificates and cipher policy, database administration to protect MariaDB, MySQL or PostgreSQL and verify backups, and Java application operations to handle Tomcat or Jetty, WAR deployments and module updates. You also need people who can review roles and privileges against clinical responsibilities. Teams that lack one of these areas usually lose more time to learning than to the hardening itself. A partner adds the most value where a skill or the time for independent review is missing.

What do we need to provide before hardening starts?

Your organization supplies the information and access that let the work start without guesswork. Typical inputs include an inventory of hosts and sites with their roles, network diagrams showing how clinics, the gateway, the application server and the database connect, access to the certificate authority or to the process that issues certificates, database administrator access for the instances in scope, and a test environment close enough to production to test changes safely. You also need a named owner for each access review who approves role and privilege changes. Confirm the complete list in the written scope, since it varies by deployment.

Does DeployOpen issue a security certification for OpenMRS?

No. DeployOpen does not issue security certifications, attestations or audit reports. It prepares systems, configuration, documented controls and evidence so that an independent auditor or certification body can assess them against the framework your organization follows. Ask your assessor which evidence they expect before work begins, so the hardening scope and evidence collection match that framework. Configuration baselines, access review records, certificate inventories and restore test results are common examples, but confirm the exact list with the assessor, since expectations differ between frameworks and organizations.

Will hardening change how clinicians use OpenMRS day to day?

It can. Hardening often changes what users can see and do, mainly through role and privilege changes. A clinician who could previously reach a form, report or administrative function may lose that access after the changes. Stricter session timeouts, password policy or single sign-on changes can also affect daily routines. Plan a role mapping exercise with clinical leads, test the affected workflows in the test environment, and give users notice in advance that describes what will change and who to contact for help. Confirm the change list and who is responsible for communication in the written scope.

What security work remains after OpenMRS go-live?

Several security tasks recur after go-live and each needs a named owner. Patching covers the operating system, the Java runtime, Tomcat or Jetty, the database, and the OpenMRS core and modules, each checked against its own release notes. Certificate renewal needs a calendar and a tested renewal process. Access reviews should run on a schedule and remove accounts that no longer need access. Restore tests confirm that backups can be recovered, and they should run on a regular cycle. A retainer can cover some or all of this ongoing work. The scope should state which tasks it includes and how changes are tested before release.

What drives the cost of OpenMRS hardening in a quote?

Cost depends on the work in the written scope. DeployOpen does not publish a price list, and a quote follows from that scope. The main drivers are the number of hosts and sites, the depth of role and privilege review, the number and condition of custom modules, the amount of TLS and certificate work, and how much testing you need before release. One-time work includes assessment, configuration and testing. Recurring work includes patching, certificate renewal, access reviews and restore tests, which a retainer can cover. Ask each quote to separate one-time and recurring items, name who performs each task, and list your inputs and assumptions.

How DeployOpen scopes, hardens and hands over OpenMRS environments

DeployOpen works on OpenMRS security hardening inside the client's own infrastructure, whether cloud accounts, data centers or air-gapped networks. We agree a written scope first, then harden the deployment that holds patient records, document what changed, and hand it over with the evidence the client's team and assessors will need.

How we scope

Engagements are fixed-scope, with the systems, environments and controls in the OpenMRS hardening work agreed in writing before any change is made.
We inventory the deployment paths in use, such as the Standalone package, a Tomcat WAR with MySQL, or the O3 Reference Application Docker Compose stack.
The scope names which items are covered, including TLS at the gateway, default credentials, database protection, roles and privileges, backups and module patching.

How we build

We review the gateway and TLS configuration, including any Certbot-managed certificates in the O3 Docker Compose setup, and set the TLS policy in the written scope.
We replace default credentials, restrict database access for the MariaDB, MySQL or PostgreSQL instance, and review OpenMRS roles and privileges against the agreed access model.
We test hardening changes in a non-production copy first, then check module versions and any authentication modules, such as OAuth2 Login, before release.

How we hand over

We deliver a change record listing each hardening setting, its location in the deployment and the reason for the change.
We document backup and restore steps, verification results and the module versions in use, so the client's team can repeat the checks.
We walk the client's operators through the runbook and record open items that need an owner in the client's organization.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing alongside the hardening work.
Patching of OpenMRS Platform, O3 Reference Application and modules can be scheduled and tested before it reaches production, under an agreed plan.
Ask in any quote which support hours, response expectations and testing cycles are included, and confirm them against your own environment and the OpenMRS project's release notes.