How do you start Orthanc security hardening on a server that holds patient images?
Start by treating the server as closed until you deliberately open it. By default Orthanc only accepts HTTP connections from localhost, so a fresh install is not reachable by clinicians or modalities over the network. The first decision is therefore which access paths the site actually needs, and for each one, which control protects it. If the answer includes any remote browser or API access, the documentation expects you to enable remote access together with authentication, define users in the RegisteredUsers list, and serve traffic over HTTPS, usually through a reverse proxy when the server is exposed beyond the internal network.
Do not assume that one switch covers the whole server. Orthanc exposes several separate surfaces, and each needs its own decision: HTTP authentication for the REST API and Orthanc Explorer, encryption for DICOM traffic (DICOM TLS, which Orthanc supports for inter-site exchanges starting with version 1.9.0), encryption of stored files, and the dangerous REST routes. The security FAQ warns that the /tools/execute-script route can let a malicious user run any system command and that the export route can overwrite files, so both should stay disabled unless you have a specific, reviewed need for them. Write these decisions down as a table with one row per surface, the current setting, the target setting and the owner of that setting.
The difficulty is that these settings interact. Turning on remote access without authentication exposes the API, but enabling authentication alone does not protect a reverse proxy that forwards requests to an unauthenticated port, or a DICOM listener that still accepts unencrypted associations from any host. Disabling the script route does not help if a plugin or a proxy rule re-exposes the same path. Storage encryption protects files at rest but does nothing for an authenticated user who can already download studies through the API. A fix in one place can leave another open, so each change should be checked from the outside, not only in the configuration file.
To start, inventory who and what connects to the server: clinicians with browsers, modalities and workstations sending DICOM, other sites, backup jobs and any integration software. For each connection, confirm with the people who own it whether it crosses a network boundary and whether it carries patient data. Then ask your Orthanc administrator or partner to confirm the exact configuration keys and plugin behavior for your release, since settings and defaults can change between versions (the 1.13.0 release, for example, changed storage-area access and DICOM parsing). Plan a verification pass after each change: an unauthenticated request from outside the trusted network should fail, and the disabled routes should return an error.
Which Orthanc settings and extension points control access and transport?
Orthanc's access and transport controls span the configuration file, the reverse proxy, DICOM networking and the plugins that handle identity. Read them together, because a permissive network setting can undo strong authentication, and an unprotected route can bypass both. Storage encryption at rest is a separate control that depends on your storage layer, so confirm it with your storage team.
Remote access flag
RemoteAccessAllowed decides whether Orthanc accepts HTTP connections from hosts other than localhost. The default posture is localhost only, so the REST API and Orthanc Explorer are unreachable from the network until this flag is enabled. Before turning it on, confirm which network segments need access, and check that the host firewall and the listening interface match that decision. Do not treat this flag as access control, because it only determines whether remote clients can reach the server at all.
Authentication and registered users
AuthenticationEnabled requires credentials on REST requests, and RegisteredUsers defines the accounts that may present them. The Orthanc Book advises setting AuthenticationEnabled to true with users defined in RegisteredUsers whenever RemoteAccessAllowed is enabled. Check that every account has a unique, strong password, that sample or default credentials are removed, and that the configuration file is readable only by the service account. The list is maintained by hand, so agree on an owner and a rotation process before go-live.
Reverse proxy for HTTPS
The Orthanc Book recommends HTTPS and a reverse proxy when the server is exposed to the Internet. The proxy terminates TLS, so certificates, protocol versions and cipher policy are managed in one place. Confirm that Orthanc listens only on an internal interface, that the proxy forwards only the routes you intend to expose, and that proxy access logs are retained. The proxy does not replace Orthanc authentication, because forwarded requests still need valid credentials or an authorization decision.
DICOM TLS for inter-site exchange
DICOM TLS encrypts DICOM associations between Orthanc and peer modalities or other sites. The Orthanc Book states that Orthanc supports it starting with version 1.9.0, so confirm the release in use before planning. Both ends must agree on TLS settings and certificate trust, and the remote system must support DICOM TLS as well. Misconfigurations often surface first as failed associations, so test each peer and record which application entities are permitted to connect.
Script execution and export routes
The Orthanc Security FAQ warns that the /tools/execute-script route can let a malicious user run any system command on the server, and that the export route can overwrite files. Both should stay disabled by default in any hardened deployment. Check both the configuration file and the running instance, and confirm that no integration, viewer or script depends on these routes. If a team needs one of them, document the owner, the approval and the audit trail before enabling it.
Advanced authorization plugin
The advanced authorization plugin forwards each REST request's token to an external web service, which decides whether access is allowed and returns HTTP 403 when it is denied. The orthanc-auth-service reference project pairs this with Keycloak-issued user tokens and Orthanc Explorer 2. This moves identity and policy outside Orthanc, so the external service becomes a security-critical dependency. Confirm its availability, token validation, logging, and the behavior of Orthanc when the service is unreachable.
Which access model fits your Orthanc deployment?
This table compares four ways to control who can reach an Orthanc server and what each option asks of your team. Read each row for the right fit, the ongoing operational work, and whether DICOM TLS needs a separate decision for each modality or peer. The main takeaway is that wider reach brings more user, certificate and service work, and DICOM TLS is decided per peer in every case.
| Access model | When it fits | Operational cost | DICOM TLS need |
|---|---|---|---|
| Localhost only, no remote users | A single server where only local tools call the REST API and modalities reach the DICOM port on a closed, segmented network. | Lowest effort. No user accounts to manage, but local access depends on the host's own login controls and admin rights. | Confirm per modality. Plain DICOM may be acceptable on a closed network if you document that decision and its review. |
| Remote access with AuthenticationEnabled and RegisteredUsers | Small teams reaching Orthanc from other machines on a controlled network, with a short and stable user list. | Ongoing user lifecycle work: adding, removing and rotating credentials in configuration, with a documented joiner and leaver process. | Separate from HTTP login. Needed for DICOM only where the peer supports TLS. Confirm with each modality vendor. |
| HTTPS through a reverse proxy for Internet exposure | Any access from outside a controlled network, or where browsers and viewers need a certificate that clients already trust. | Certificate issuance and renewal, proxy configuration, timeouts for large downloads, and patching of the proxy itself. | Not applicable |
| Advanced authorization plugin with an external service | Per-user or per-study decisions, or identity provider integration, where a static RegisteredUsers list is too coarse. | Runs and secures an extra web service, maintains access policies, and tests each REST route against them after every upgrade. | The plugin covers REST requests only. DICOM peers still need their own TLS and allow-list decisions. |
How do you harden an Orthanc server step by step?
This sequence takes a default Orthanc server and reduces what can reach it, who can use it and what the server can do on its behalf. Each step ends with a check you can rerun, so the result is evidence you can show a reviewer.
Inventory settings and exposed ports
The server administrator starts by recording the active configuration file values, including the REST and DICOM ports, listening addresses, enabled plugins and the routes the team actually uses. Then scan the host from another machine on the same network to compare the open ports with the written baseline. This step is done when every open port has a named owner and every loaded plugin has a documented reason to be there. Anything unexplained is removed or reviewed before you change any setting.
Keep the REST API on localhost
Leave the REST listener bound to localhost and keep remote access disabled while the access design is still open. Remote users, modalities and the reverse proxy are not yet configured, so nothing needs the open interface. The administrator confirms this step by sending an HTTP request to the REST port from another host, which must be refused or time out, and by sending the same request from the server itself, which should succeed. Record both results in the change log.
Enable remote access only when needed
Set RemoteAccessAllowed to true only for the clients that have a documented need, and only after the reverse proxy design is agreed. The Orthanc security FAQ says that when remote access is enabled, AuthenticationEnabled should be true with users defined in RegisteredUsers, so change those settings together. Limit network access at the firewall to the proxy host and approved clients. The check is that an unauthenticated request from an allowed client fails, and a request from an unlisted network does not reach the service.
Enable authentication with defined users
Turn on AuthenticationEnabled and create one named account in RegisteredUsers for each person or service that needs access. Give each account its own credential, remove any default or sample accounts, and record who owns each entry and who approves changes. Shared accounts make later access reviews and incident investigations difficult, so avoid them. The step closes when a study request with no credentials fails, a request with a wrong password fails, and a request from a valid account returns the expected data.
Place the API behind a TLS reverse proxy
Put a reverse proxy in front of the REST API to terminate HTTPS with certificates issued under your organization's certificate process, and forward only the routes that users need. Confirm who renews the certificates and how renewal failures are alerted. The Orthanc listener should accept connections only from the proxy. The check is that plain HTTP to the public name is refused, HTTPS with a valid certificate succeeds, and requests reaching Orthanc originate from the proxy address rather than from client machines.
Configure DICOM TLS with each peer
Enable DICOM TLS for exchanges with sites that support it, which the Orthanc security FAQ notes has been available since version 1.9.0. Agree certificate handling with each peer and keep a current list of allowed AE titles and addresses. Any peer that cannot negotiate TLS needs a documented exception and compensating network controls approved by the security owner. The step is complete when an association from an unlisted AE title is rejected and a TLS-enabled peer completes a C-ECHO verification over TLS.
Disable script and export routes
Keep the /tools/execute-script route and the export route disabled. The Orthanc security FAQ warns that the first can let a malicious user run system commands and the second can overwrite files. If a clinical or research workflow appears to need export, route that need to a reviewed integration owned by the platform team and not to an open endpoint. The check is that requests to both paths return an error and that the proxy configuration does not forward either path.
Review storage encryption and file permissions
Confirm that the storage directory and database files are readable only by the Orthanc service account and the administrators who manage backups. Agree with the security team how data at rest is encrypted, whether through full-disk encryption, an encrypted volume or the encryption features of the storage platform in use, and confirm these details with the storage vendor or cloud provider for your environment. The step closes when a local user other than the service account cannot read a stored instance file and the encryption method is written into the configuration record.
How does hardening differ for a single node, a reverse-proxied server or an air-gapped network?
A single Orthanc server reachable only from a hospital or enterprise LAN is the simplest model, and it is the one most often under-protected because the network is assumed to be trusted. By default Orthanc only accepts HTTP connections from localhost, so the first decision is whether remote access is needed at all. If it is not, leaving RemoteAccessAllowed disabled keeps the REST API off the network interface. Where clinicians or modalities do need access, the controls that matter most are enabling authentication with users defined in RegisteredUsers, restricting which hosts may reach the DICOM and HTTP ports with host firewall rules, and keeping the dangerous REST routes disabled.
What to harden in this model:
- Remote access: keep RemoteAccessAllowed off unless a named set of users needs the REST interface.
- Authentication: when remote access is on, set AuthenticationEnabled to true and define each user explicitly.
- Dangerous routes: keep the script execution and export routes disabled, as the security FAQ recommends.
- Certificates and DNS: internal certificates may come from an internal CA, but confirm that every client trusts that CA and that the server name clients use matches the certificate.
- DICOM TLS: only needed when a peer is at another site, so it often does not apply here.
Hard to verify: internal networks change over time, so confirm that firewall rules still match the list of approved modalities and workstations after each change.
When remote users, external viewers or partner sites reach Orthanc over the Internet, the reverse proxy becomes the main control point. The security FAQ recommends HTTPS and a reverse proxy for Internet exposure, so Orthanc itself should stay on a private interface and only the proxy should accept outside connections. Authentication still belongs in Orthanc, and many teams add a second layer at the proxy or through the advanced authorization plugin, which forwards each request's token to an external service that returns HTTP 403 when access is denied. The proxy configuration itself is part of the hardening scope.
What to harden in this model:
- Single entry point: only the proxy listens on public addresses, and Orthanc is bound to a private interface.
- TLS termination: decide where TLS ends, then ensure forwarded headers are trusted only from the proxy.
- Certificates and DNS: issue a public certificate for the external name, keep renewal automated, and make sure the internal name used by Orthanc is not published.
- Request limits: set body size, timeout and rate limits at the proxy so large uploads and scripted queries are controlled.
- DICOM TLS: apply it to DICOM peers at other sites, separately from the HTTPS path that the proxy handles.
Hard to verify: proxy rules drift when someone changes a route or header. Confirm with an external scan and a test that a direct request to the Orthanc port is refused from outside the network.
An air-gapped or isolated network has no route to the Internet, so the threats are mostly internal: misconfigured clients, removable media, and peers that cannot be reached for updates. Certificate and DNS work is different because there is no public certificate authority or public DNS to rely on. The organization must run or supply an internal CA, distribute its root to every client and modality that connects, and keep an internal name service that resolves each Orthanc and peer. Updates and plugin packages must be brought in through a controlled transfer process, so the upgrade path is part of the security design.
What to harden in this model:
- Certificates and DNS: plan an internal CA, certificate lifetime and renewal before go-live, and document the trust store on each client.
- DICOM TLS between sites: where an isolated network connects to a peer at another site, DICOM TLS (supported from version 1.9.0) needs a shared trust plan with the other site's administrators.
- Media and transfer controls: define how packages and images enter and leave the network, and scan them.
- Authentication and routes: the same RegisteredUsers and disabled-route settings apply, with local accounts reviewed on a schedule.
- Logging: keep audit logs on the isolated network, since no central service may be reachable.
Hard to verify: without outside connectivity, external scanning and vendor advisory checks are limited. Ask the team to confirm how they will test patch status and certificate expiry from inside the network.
Which dangerous routes and secrets must be locked down first?
Each card covers one item that can expose patient images or let an attacker run commands on the server. Start with the two dangerous REST routes, then review credentials, accounts, logs and storage encryption. Confirm each setting against the Orthanc Book version you run, because route names and configuration options can change between releases.
Disable the script execution route
The /tools/execute-script route allows a caller to run scripts inside the Orthanc process. The Orthanc security FAQ warns that a malicious user could use it to run any system command on the host that holds the patient images. Confirm in the Orthanc Book version you run that the route stays disabled, check that your reverse proxy does not forward it, and test by requesting it from outside the trusted network. The request should fail.
Block the export route
The export route can overwrite files on the server, so the Orthanc security FAQ advises keeping it disabled. Before you turn it off, confirm with each integration owner that no workflow depends on it. Ask for the export-related settings in your Orthanc version, and record which routes each integration calls so that a proxy rule does not expose a route nobody reviewed.
Keep credentials out of configuration files
Orthanc reads its settings from JSON configuration files, and the RegisteredUsers list defines user names and passwords. Database passwords, object storage keys and DICOM TLS key material often sit in the same directory. Move these secrets into a secret store or environment-level injection, restrict file permissions on the configuration directory, and check that backups and container images do not contain them in plain text. Confirm the supported injection method for your version.
Run with least-privilege accounts
Set AuthenticationEnabled to true whenever RemoteAccessAllowed is on, and define each user in RegisteredUsers with only the access that user needs. Give the database and object storage accounts only the rights the Orthanc process uses, and run the service under a non-administrative operating system account. If you use the advanced authorization plugin, test denied requests as well as allowed ones, because the external service must return HTTP 403 for access it refuses.
Keep patient identifiers out of logs
Orthanc and its reverse proxy write logs that can reveal request paths, and request paths can include study or patient identifiers. Depending on the log level, DICOM details may also appear in messages. Review the log level, log file location, retention period and read access for each log source. Confirm in the Orthanc Book version you run which events record tags, and store logs in a restricted location.
Choose storage encryption at each layer
Encryption can sit in the file system, the database, the object storage backend or the transport. DICOM TLS addresses exchanges between sites from Orthanc 1.9.0 onward, so encryption of images at rest needs its own answer. Ask each storage plugin or backend which encryption at rest and key management options it provides, confirm who holds the keys and how they rotate, and verify the result by checking the stored files directly.
How do you verify that Orthanc security hardening works and fails safely?
The hardening settings only protect patient images if a team proves, after every change, that refused requests are refused and that failures stop access instead of opening it. Build a short test suite for the Orthanc server and run it before go-live, after each configuration change and after each Orthanc upgrade. Start with the outside view. From a machine that is not on the local host, send unauthenticated requests to the REST API and confirm they are refused. Then confirm that the remote access setting, authentication, and the RegisteredUsers list behave as your change record says they do. Run the same requests through the reverse proxy and directly against the Orthanc port, because a proxy misconfiguration often shows up as a route that works from one path and fails from the other.
Next, test the routes the security FAQ says should stay disabled. Request the script execution route and the export route with valid and invalid credentials, and confirm each returns an error and performs no action. Check the Orthanc configuration file and the running instance separately, since a route can be enabled by a setting you did not expect. For transport, confirm that plain HTTP does not answer from outside the proxy at all, and that the HTTPS endpoint presents the certificate you expect. For DICOM, use a test modality that does not speak TLS to attempt an association with a TLS-only peer, and confirm the association fails. Repeat the attempt with a modality configured with the correct certificate and confirm it succeeds. Failing closed matters most here: remove or expire the server certificate in a test environment and confirm that access is blocked, not silently served over an unencrypted or untrusted channel.
Retest after every Orthanc upgrade. Release notes can change defaults, DICOM parsing and storage access, so a test that passed on the previous version is not evidence for the new one. The Orthanc NEWS file lists each release, and the 1.13.0 entry describes a rewrite of storage-area access and DICOM parsing and transcoding, which is a reason to repeat the full suite rather than a sample. Also retest when a plugin, the reverse proxy, or the certificate authority changes. Ask your vendor or the Orthanc maintainers to confirm any default that affects these tests before you rely on it.
Record every test with its date, the Orthanc version, the configuration file hash, the tester, the expected result, the actual result and the screenshot or log extract that shows it. Store these records with the change ticket so an auditor can trace a control to a result. Be clear about the boundary here: DeployOpen runs security testing of applications and infrastructure, and it can help you design these tests, run them against your environment and document the results. An independent auditor or certification body issues any assessment result or attestation, so the test log is evidence you provide to that auditor, not a conclusion you can present as one.
What should you monitor, back up and document after hardening?
This sequence keeps an Orthanc server that holds patient images in the hardened state after go-live. It covers account hygiene, log review, certificate tracking, configuration control, tested recovery, regression testing on each release, and an evidence record for the compliance team.
Review user accounts and remove leavers
The administrator who owns Orthanc reviews every entry in the RegisteredUsers list against the current staff roster on a schedule the organization sets in its access policy. Each account is confirmed as still needed, its role is checked, and accounts for leavers and unused service identities are deleted, with the configuration reloaded afterward. Done means a dated review record lists each account, its owner, and the change made. If the team uses the advanced authorization plugin with an identity provider, confirm that disabling a user there also blocks Orthanc access, since local entries may not be the only control.
Watch authentication failures and proxy logs
Someone on the operations team reviews Orthanc's own log output for failed logins and the reverse proxy's access and error logs for unusual request patterns, such as repeated authentication failures, requests to routes that should be disabled, and access from unexpected networks. Confirm the log level and the destination, and confirm who receives alerts. Done means logs are shipped to a location the operations team can search, a named person reviews them on the cadence in the runbook, and any finding has a ticket with an outcome recorded.
Track certificate expiry for the proxy and DICOM TLS
The team keeps an inventory of every certificate in use: the HTTPS certificate on the reverse proxy and any certificate used for DICOM TLS with partner sites. Each entry records the issuer, the expiry date, the renewal owner and the place the certificate is installed. Expiry alerts are set in the monitoring tool well before the date, and the renewal is tested in a non-production copy. Done means every certificate appears in the inventory with an alert, and a renewal has been rehearsed at least once so the team knows the steps.
Version the configuration and keep secrets out of it
The Orthanc configuration file, reverse proxy configuration and any deployment scripts are stored in a version control system with reviewed changes. Passwords, tokens and private keys are kept in a dedicated secrets store or injected at runtime, so the repository holds only references. Done means a clean repository check shows no credentials in committed files, every production change maps to a reviewed commit, and the team can name who approved the last change to each security setting.
Back up configuration and database with a tested restore
The backup plan covers the Orthanc configuration, the database that indexes the studies, and the storage area where the DICOM files are kept. Backups run on the schedule set in the operations runbook, and copies are stored separately from the primary system. Someone restores a backup into an isolated environment, confirms the server starts, and checks that a sample of studies opens and matches expected counts. Done means a restore test record exists with the date, the backup used, the checks performed, and the time it took. The schedule and retention period should come from the organization's own policy and the database engine's documentation.
Re-run verification tests after each release
Each time the team plans an Orthanc core or plugin upgrade, the verification tests from hardening are repeated on a staging copy before production. These cover anonymous access being refused, remote access requiring authentication, the dangerous routes such as script execution and file export remaining disabled, and DICOM TLS connections to partner sites still succeeding. Done means the test results for the new version are recorded and compared with the previous baseline, and any failure blocks promotion until resolved. Check the release notes for the target version before testing, since changes to storage or parsing can affect the tests.
Record decisions and test evidence for compliance
The team maintains a single evidence file that lists each hardening decision, the reason for it, the owner who approved it, and the test that shows it is in place. Access reviews, log reviews, certificate inventory entries, restore tests and release verification results are filed alongside it with dates. This file is what the compliance team and any independent auditor will ask to see. Done means the compliance lead has reviewed the evidence file, every control has at least one dated artifact, and gaps are logged with an owner. DeployOpen can help prepare systems, controls and evidence for an assessment, but audit reports and certifications are issued by independent auditors and certification bodies.
What drives the effort and cost of Orthanc security hardening?
This table lists the factors that change how much work an Orthanc hardening project involves, and for each one, a way to keep the effort contained. Use it to see which answers in your environment will move a quote up or down before you request one. Scope drivers such as user count and Internet exposure matter most, because they decide how much access control and proxy work must be built.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of users and roles | Each role needs its own permissions, and the built-in RegisteredUsers list has no per-study rules, so more roles means more access design and testing. | Agree a short role list before work starts and map each role to one permission set. |
| Modalities and external peers needing DICOM TLS | Every scanner, workstation or partner site that must connect over encrypted DICOM needs certificates, trust settings and a connection test. | Group modalities by site and certificate authority, and confirm which peers truly need TLS in the first phase. |
| Internet exposure | Remote access brings in HTTPS termination, reverse proxy rules, rate limits and external penetration testing, which add the most work. | Limit remote access to named networks or a VPN, and expose only the routes users actually need. |
| External authorization service built or integrated | A custom token-checking service must be designed, built, tested and kept in step with Orthanc releases. Integrating an existing service is smaller work. | Reuse an existing identity provider and an existing authorization service where one is already in place. |
| Existing identity provider integration | Connecting to a provider that already manages staff accounts takes less design than creating a separate user store and its lifecycle process. | Reuse the organization's current identity provider and confirm group or role claims early. |
| Number of environments | Development, test and production each need matching settings, separate secrets and a repeatable way to promote changes. | Keep one configuration template with environment-specific values, and deploy it the same way everywhere. |
| Depth of logging and evidence required | Audit trails, log retention, access reviews and evidence for compliance readiness need more design and more verification steps. | Agree the evidence list with the assessor or compliance lead before configuration begins, then collect only that evidence. |
| Number of Orthanc instances | Each instance needs its own settings review, route checks and proxy configuration, and multi-instance setups add shared database considerations. | Standardize the proxy configuration and the Orthanc configuration file so that one tested pattern is repeated. |
What do buyers ask before hiring help with Orthanc security hardening?
How much does Orthanc security hardening cost?
Cost depends on the scope agreed in writing and on several drivers. The main ones are how many Orthanc instances and environments need work, whether the server sits behind a reverse proxy that must be configured for HTTPS, whether DICOM TLS is needed for links to other sites, how many scripting, export and storage routes must be reviewed and locked down, and whether storage encryption is in scope. Each item adds analysis, configuration, testing and documentation time. Expect one-time work for the hardening itself, plus a separate recurring cost if you also want patching, upgrades or ongoing support. DeployOpen does not publish prices, so a quote follows from the written scope. Ask for the components to be itemized: assessment, configuration changes, verification testing, handover documentation and any retainer for ongoing work.
Can our in-house team harden Orthanc without a partner?
Yes, a skilled team can do much of the work if it has time, server access and a test environment. The core settings are described in the Orthanc Book security FAQ: keep remote access off unless you need it, enable authentication when remote access is allowed, define users, use HTTPS and a reverse proxy for any Internet exposure, enable DICOM TLS for inter-site exchange, and disable the script execution and export routes. The harder part is verification. Your team must confirm that each blocked route stays blocked, that the proxy passes the right headers, that certificates renew, and that upgrades do not reopen settings. Check whether your engineers have DICOM and modality network experience, since changes to connections can disrupt scanners and workstations. Decide early who will own the configuration after handover.
What information do we need to give before a hardening engagement starts?
Expect to provide a short set of inputs before work begins. You will need network diagrams showing where Orthanc, the reverse proxy, firewalls and imaging modalities sit. You will also need the peer list of DICOM nodes that send or receive studies, with AE titles, hostnames and ports. Name the certificate authority you use, or describe how server and client certificates are issued, because HTTPS and DICOM TLS both depend on it. Provide the user list with roles, plus any existing identity provider. Include the current Orthanc version, the plugin list, the configuration files, your hosting platform and the location of backups. Records of previous incidents or audit findings also help. Missing inputs tend to lengthen the discovery phase, so confirm access and named owners early. Ask the partner to list these inputs in the written scope.
How long does an Orthanc security hardening engagement usually take?
Duration depends on the number of servers, the environments in scope, how much network and certificate work already exists, and how quickly your teams return approvals and test results. Engagements generally move through discovery, a configuration plan, changes in a test environment, verification and a production change window with handover. Most DeployOpen engagements are fixed-scope, so the timeline is agreed in writing with that scope. No duration is given here because the right answer depends on your environment. Ask for a timeline with milestones tied to your inputs, and note which steps wait on your change board, certificate issuance or network team. A timeline that does not show these dependencies is harder to hold a vendor to.
Do Orthanc Team support hours cover security hardening work?
Usually not as the main vehicle. Orthanc Team SRL sells deployment, configuration and development services, along with pre-paid dedicated support hours that are valid for 12 months and quoted on request. Those hours suit questions about Orthanc behavior, a specific defect or a plugin problem, and they can confirm whether a setting does what you expect. Security hardening is a separate piece of work with its own scope: reviewing your network, proxy, certificates, user model and routes, then verifying the result. You can buy both, but do not assume hours bought for troubleshooting will cover a full review. Ask the vendor to state in writing what the hours include, how they are logged, and whether they cover changes to production.
Does hardening Orthanc alone make our imaging system compliant?
No. Hardening reduces exposure, but it does not make a system compliant with any framework by itself. Compliance also depends on your policies, risk assessment, access reviews, logging, backup and recovery testing, vendor management and the evidence you keep, along with the rules that apply to your organization and jurisdiction. DeployOpen prepares controls and evidence for compliance assessments, mapping the hardened configuration to the controls you are assessed against. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Ask any partner which evidence they will deliver, in what format, and which items remain your responsibility after handover.
How do we limit which users see which studies in Orthanc?
The built-in RegisteredUsers list handles authentication, but it does not provide per-study access control on its own. Per-study permissions usually call for the advanced authorization plugin, which forwards each REST request's token to an external web service. That service decides whether access is allowed and returns HTTP 403 when it is denied. The design, including how an identity provider such as Keycloak fits in, is covered in the Orthanc SSO with Keycloak and access control topic, so it is not repeated here. The decision to flag now is scope: if clinicians need different study visibility, plan for an authorization service and an identity provider from the start. Hardening a server that only has a user list will not give you study-level separation. Confirm the approach against your access policy before design begins.
How does DeployOpen scope, build and hand over Orthanc hardening?
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and Orthanc hardening follows the same arc. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.
How we scope
- Inventory which Orthanc endpoints, DICOM ports and plugins are enabled on the server today
- Confirm remote access needs, the user population and whether Internet exposure is planned
- Agree in writing which items are in scope, such as reverse proxy, DICOM TLS and storage encryption
How we build
- Apply authentication, HTTPS behind a reverse proxy and DICOM TLS settings in a staged environment first
- Disable dangerous REST routes such as script execution and file export, then verify they stay unreachable
- Test each change against the modalities and viewers that depend on the server before promoting it
How we hand over
- Deliver configuration files, a hardening record and the verification results for each control in scope
- Document the settings to revisit at each Orthanc release, including the 1.13.0 upgrade path
- Walk through the runbook with the team that will operate the server after handover
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, separate from the fixed-scope work
- Re-check hardening settings when plugins, viewers or the reverse proxy change
- Confirm with DeployOpen what support coverage the written scope includes before signing
