Why CKAN security hardening is separate work after installation
A CKAN portal that works is not yet a hardened portal. Hardening means configuring each component that is exposed, including the web server, the CKAN application itself, the PostgreSQL DataStore, Solr, Redis, uploaded files, API tokens and every third-party extension, and it means keeping the CKAN release line on a version that still receives security fixes. A team preparing a portal for publication or for an assessment should treat these as two separate workstreams, each with its own owner and evidence. The work is harder than it looks because CKAN is not a single service. A typical production deployment runs a web server in front of the application, the application itself, a PostgreSQL database for metadata and a separate database for DataStore, a Solr search index, and Redis. Each of these listens on its own interface, accepts its own credentials and fails in its own way. A portal can be reachable only through its front door and still expose a search or cache service to the wider network if the internal network rules were never reviewed. Confirm, for each service, which addresses it binds to and which hosts can reach it.
Extensions add a second layer. CKAN's functionality is extended through ckanext packages, and each one carries its own code, Python dependencies and configuration options. The DCAT extension, for example, adds RDF endpoints and a harvester that imports from other catalogs, and the SAML2 extension changes how users authenticate. Each of these changes the attack surface. Before a portal is published, the team should inventory every installed extension, record its version and source, and confirm that its dependencies are covered by the same patch process as the core platform. Extensions that are no longer maintained should be removed or replaced rather than carried forward on trust.
The release line matters as much as the configuration. CKAN targets about two minor releases a year, and the project supports only the latest patch of the current minor version and the previous minor version for security and bug fixes. Once a newer patch is released, older patches lose support. A portal that was hardened against one release line can drift out of support without any configuration change. Ask the project's release policy which versions are supported on the date you plan to publish, and check that the chosen version is still in that window at the time of the assessment, not only at go-live.
For planning purposes, separate the hardening scope into four questions: which services are exposed and to whom, which credentials and tokens exist and who can issue them, which extensions are running and who maintains them, and which CKAN release and patch are in use. Each answer produces a control, a setting or a record. A portal that cannot answer all four with evidence is not ready for an assessment, however well the installation was done.
Which CKAN components widen the attack surface
A CKAN portal is a set of services that each accept input from different people. The application, database, search index, cache, file loading path, API and extensions all need explicit settings, because a default that suits a development install can expose more than a public portal should. The cards below list what each component exposes, who can reach it and the setting that needs a decision.
CKAN application behind uWSGI and Nginx
The CKAN application is the public-facing layer, and the install guide recommends serving it through uWSGI with Nginx in front for production. Check that only Nginx listens on public interfaces, that the application process is not exposed directly, and that debug mode is off. Confirm the web server configuration sets request size limits and passes the expected headers, since both affect uploads and login flows.
PostgreSQL and the separate DataStore database
CKAN keeps its main database and the DataStore in separate PostgreSQL databases, and the DataStore has a write user and a read-only user. The read-only user is what the Data API and public SQL queries should use, so confirm its grants cover only the DataStore tables and nothing in the main database. Restrict network access so the database accepts connections only from the CKAN hosts.
Solr 9 search index
Solr 9 is the recommended search version, and Solr 8 is also supported. The index is usually reached only by CKAN, but it can be exposed by mistake through a default port or an admin interface. Confirm the Solr port is bound to a private network, that the admin console is not reachable from users, and that the Solr version is one the CKAN release supports.
Redis cache and session store
Redis holds cached data and supports CKAN's runtime behavior, so anyone who can write to it can influence what the application reads. Redis is not designed to be exposed to untrusted networks. Check that it listens only on the internal interface, requires authentication where your deployment supports it, and is not reachable from the public web tier.
Upload and XLoader path into the DataStore
Publishers upload files or link to remote files, and XLoader loads them into the DataStore. This path turns untrusted content into database tables, so it needs limits on file size and type, a review of which roles can submit resources, and logging of load failures. XLoader is the supported loader, and DataPusher is legacy, so confirm which loader your portal runs before setting these limits.
Data API and API tokens
The Data API serves DataStore records and SQL queries to anyone who can reach it, and API tokens authenticate writes and private data access. Decide which operations anonymous users may perform, confirm SQL access runs only through the read-only database user, and set token lifetimes and owners deliberately. Review which accounts hold tokens with elevated rights, because a leaked token acts with that account's permissions.
Third-party extensions such as ckanext-dcat and ckanext-saml2auth
Extensions run inside the CKAN process with the same access as the core application, so each one widens the attack surface. ckanext-dcat adds RDF endpoints and a harvester that imports from other catalogs, and ckanext-saml2auth changes how users authenticate. For each installed extension, confirm the version matches your CKAN minor release, review which endpoints it adds, and record who approved it. SSO configuration details are covered on the CKAN SSO page.
Which exposure and access choices to make before configuring
This table compares the five exposure and access decisions that shape a CKAN hardening plan, with the operational cost of each option. Read each row as a choice to settle with the platform owner, the data owners and the support team before any configuration starts. The main takeaway is that the tighter option almost always adds access requests, token rotation or support load, so decide those costs up front.
| Decision | When it fits | Operational cost |
|---|---|---|
| Solr and Redis on a private network only | Almost every production portal, since Solr and Redis are backend services that CKAN reaches over the network and that users never need to reach directly | Administrators reach the search index and cache through a bastion, VPN or jump host, which adds access requests for debugging and reindexing |
| Solr and Redis reachable from other hosts | Only when a separate search or cache cluster serves several applications and network controls already restrict who can connect | Firewall rules, service authentication and network segmentation must be maintained and reviewed, and every new consumer needs a change request |
| DataStore queried only through the Data API | Portals that publish tabular resources for public use and do not need ad hoc database access for analysts | Analysts who want full SQL depend on the portal team to add queries or exports, which increases support tickets for custom reports |
| DataStore also open to direct SQL access | Research or analytics teams that need joins and aggregations, with a read-only database user kept separate from the write user | Each analyst account needs a credential, role review and rotation, and the team must watch query load on the shared database |
| API tokens issued to publishers and automation | Harvesters, scheduled uploads and publishers who script dataset updates at volume | Tokens need an owner, an expiry, a rotation schedule and revocation steps when staff leave, and the support desk handles lost or expired tokens |
| No API tokens, web login only for publishers | Small portals with few publishers who edit through the interface and do not automate uploads | Automated publishing stops working, so every bulk change becomes manual work for the portal team or the data owners |
| Uploads accepted from the public | Only where the data is intended for anonymous contribution and the team has a moderation and malware scanning process | Moderation queues, abuse handling and storage growth fall to the operations team, and file type checks must be tested continuously |
| Uploads accepted only from authenticated publishers | The default for most government and institutional portals, where every resource has an accountable publisher | Onboarding each publisher requires an account, an organization role and a training step, which adds lead time for new data contributors |
| Pin to a patch line within a supported minor version | Teams with change control windows that need predictable testing before each patch is applied | Patches still need to be applied promptly, because outdated patch releases lose support once a newer patch is out, so the calendar requires regular owner time |
| Follow the newest release | Teams with capacity to test new minor releases quickly and an extension owner who can absorb breaking changes | Minor releases may include backwards-incompatible changes, so each upgrade needs extension compatibility testing and a rollback plan |
How to harden a CKAN portal in sequence
This sequence moves a CKAN portal from a supported platform baseline to a reviewed set of extensions, one control at a time. Each step closes with a check you can repeat, so the result is evidence your security team can review. Configuration keys change between releases, so confirm them in the official CKAN documentation for your version.
Confirm the platform baseline and patch level
Start by recording the versions you run on every host. Source installs require Python 3.10 or newer and PostgreSQL 12 or newer, and Solr 9 is recommended with Solr 8 also supported. Confirm your CKAN release is the latest patch of the current minor version or of the previous minor version, because outdated patch releases lose security support once a newer patch ships. Patch releases do not change schemas or add features, so apply them promptly. Check: a written version inventory for each host that matches the release policy and the install-from-source documentation for your version.
Isolate Solr and Redis on private networking
Place Solr and Redis on a private network segment that only the CKAN web and worker hosts can reach. Neither service should accept connections from user networks, the internet, or unrelated application hosts. Bind both services to internal interfaces and restrict inbound rules to the CKAN hosts at the network layer. Then test the restriction from a host that is not a CKAN host. Check: a connection attempt from the non-CKAN host fails, the same attempt from a CKAN host succeeds, and the rules are recorded in the build documentation.
Create and test the DataStore read-only user
Set up the DataStore as a separate PostgreSQL database with one user for CKAN writes and a read-only user for Data API queries. The DataStore documentation describes this two-user model, and the configuration keys for the read-only role are in the documentation for your release. Connect as the read-only user and attempt an insert, an update and a table creation. Each attempt should be refused. Check: the read-only user runs SELECT queries through the Data API, cannot write, and the test output is saved with the build record.
Harden the web server layer
On the web tier, terminate TLS at the proxy and place uWSGI behind Nginx. Set request and body size limits in Nginx and worker limits in uWSGI so that a single client cannot exhaust the process pool. Turn off directory listing and confirm that debug output is disabled in the production configuration. The application server should accept traffic only from the proxy. Check: a TLS scan shows only the protocol settings you approved, a request to a directory path returns no listing, and an oversized request is rejected.
Control upload size, file types and loading
Set a maximum upload size and allow only the file types your publishers need. Enforce both at the proxy and in CKAN configuration. Confirm that XLoader performs DataStore loading for uploaded and linked files and that the legacy DataPusher is not active. Then submit an oversized file and a file of an unexpected type to a test dataset. Check: both uploads are rejected, and the loader logs show XLoader jobs for test resources with no DataPusher jobs.
Issue and expire API tokens
Decide who may hold API tokens, issue each token to a named user for a stated purpose, and set an expiry date for every token. Revoke tokens for staff who have left and for integrations that no longer run. Confirm the expiry and revocation settings in the documentation for your release, because setting names change between versions. Check: a token past its expiry is refused by the API, a revoked token is refused, and the active token list is kept in your access register.
Review each third-party extension
List every installed extension with its version, source and maintainer, and compare each one with the CKAN release you run. Review the code and configuration of each extension, and remove any that you do not use. Check that every extension states support for your CKAN version. For example, the ckanext-dcat repository lists the CKAN versions it supports, and the ckanext-saml2auth repository lists its requirements. Check: the inventory matches the running installation, each extension has a named owner, and no unsupported extension remains enabled.
How the CKAN patch policy shapes a hardening plan
The CKAN patch policy sets how long a hardening baseline stays valid, so the plan should be built around the support window rather than around a one-time configuration. CKAN targets about two minor releases a year. The tech team supports the latest patch of the current minor version and the previous minor version for security and bug fixes. Older patch releases lose support once a newer patch is out. A portal can therefore be on a supported minor version and still be unpatched if it is several patches behind. Hardening settings such as database role separation, Solr and Redis access rules, and API token lifetimes assume the portal will receive security fixes promptly.
CKAN patch releases do not break backwards compatibility, and they exclude schema changes and new features. That makes patches the lowest-risk change to plan for, and they can follow a standing maintenance window with a tested rollback. Minor releases may include backwards-incompatible changes, so they need a separate project with their own scope, testing and sign-off. Keep the two tracks apart in the plan: one calendar for applying patches to the current minor line, and another for moving to a new minor version. Mixing them makes it hard to tell which change caused a fault.
CKAN 2.12.0 and the maintenance releases 2.11.6 and 2.10.11 were all released on August 26, 2026. A portal on 2.10.x should move to 2.10.11 as its patch baseline and then confirm, against the release policy documentation, whether the 2.10 line remains within the supported window before planning a minor upgrade. A portal on 2.11.x should review whether 2.11.6 closes issues that affect its current configuration. Ask the team responsible for the portal to record which patch level it runs today and the date that level stopped receiving fixes.
Before applying any patch, read its release notes on the CKAN releases page and note any change to configuration defaults, templates, authentication or the DataStore. Confirm that every installed extension supports the target version. For example, ckanext-dcat lists support for CKAN 2.10 and 2.11, so a portal on 2.12 must confirm that extension's compatibility before the change is scheduled. Record the result in the change ticket, test the patch on a staging copy of the portal, and keep the previous release available for rollback until the patched portal has run cleanly.
What drives hardening effort and how to keep it down
This table lists the factors that change how much work a CKAN hardening engagement takes, why each one matters, and how to reduce it before work starts. Read each row as a lever you control, and use the reduction steps to shape scope and quotes. The main takeaway is that fewer hosts, fewer extensions, a single token policy and a documented baseline usually reduce effort more than any single technical fix.
| Driver | Why it changes effort | How to limit it |
|---|---|---|
| Hosts and environments | Each host running CKAN, the separate DataStore database, Solr or Redis needs its own configuration review, patching and verification. Production, staging and any extra DataStore host multiply that work. | Keep staging configuration generated from the same templates as production. Confirm early whether a separate DataStore host is required or can share the database tier. |
| Third-party extensions and dependencies | Each extension adds code, Python dependencies and settings to review. Old or unmaintained extensions often need patching or replacement before they meet a current CKAN minor version. | Remove extensions the portal does not use. Check each remaining extension's supported CKAN versions, such as the ckanext-dcat support for CKAN 2.10 and 2.11, and record the owner of each one. |
| Publishers holding API tokens | Every publisher account with an API token is an access path to review, and tokens with broad rights need separate checks. Inconsistent token lifetimes and revocation steps add manual investigation. | Adopt one written token policy covering who may hold tokens, expiry, rotation and revocation. Give publishers the narrowest organization role that meets their needs. |
| Upload volume and file types feeding XLoader | Uploaded files are parsed and loaded into the DataStore, so the range of formats and file sizes sets how many input paths need testing and how much resource limiting is needed. | Limit accepted formats and file sizes in the portal settings. Document which file types XLoader will process and test a representative sample before opening uploads to publishers. |
| Depth of compliance evidence | A buyer who needs control-by-control mapping and retained evidence asks for more documented configuration, change records and test output than one who needs a hardening summary. | Agree the evidence list in writing before work starts, including which controls and which artifacts. Confirm with the independent auditor which evidence they will accept, since DeployOpen prepares evidence but does not issue assessments. |
| Public internet or restricted network exposure | A portal reachable from the public internet needs stricter web server, rate limiting, and monitoring review. A restricted network still needs DataStore, Solr and Redis hardening but usually narrows the attack surface. | Decide the access model early and place Solr and Redis on private interfaces. Put only the web tier behind the public edge, and document which endpoints remain open. |
| Missing documented baseline | Without a recorded starting configuration, every review starts with discovery work, and each later change has no reference point to compare against. | Export and version the current configuration, service versions and extension list as a baseline. Repeat the export after each patch so changes can be reviewed quickly. |
Access control and secrets to lock down in CKAN
A CKAN portal exposes several access points at once: the core database, the DataStore, the search index, the cache, the upload store and the extensions that add routes. Each one needs its own credential, network boundary or review step. The cards below cover the controls that most often drift from intent, and each one should be checked against your own configuration rather than assumed from defaults.
PostgreSQL write and read-only credentials
CKAN connects to its main PostgreSQL database with a write credential, and the DataStore uses its own database and users. Keep both passwords out of version control, and load them at startup from your secrets store instead of plain text in the configuration file. Confirm the file permissions on the deployed configuration and check that no credential appears in logs, shell history or CI output.
DataStore read-only role scope
The DataStore keeps a write user and a read-only user, and the read-only user is the one that serves SQL queries from the Data API. Confirm that this role has read access only to the DataStore tables and no grants on the main CKAN database or other schemas. Test it by attempting writes and cross-database reads with that role and recording the failures.
API tokens with owner, scope and expiry
API tokens act as the user who created them, so a leaked token carries that user's permissions. Review existing tokens for owner, intended use and expiry date, and revoke any that belong to former staff or automated jobs no longer in use. Set a policy for who may create tokens with administrative rights and confirm how your CKAN version enforces expiry.
Solr and Redis private addressing
Solr and Redis are internal services, and neither should accept connections from public networks or untrusted hosts. Bind both to private addresses, restrict access with firewall rules, and enable authentication where the chosen Solr and Redis versions support it. Confirm the exact authentication options for your release in the vendor documentation before you rely on them.
Uploaded files outside the web root
Uploaded resource files and images must be stored in a directory that the web server does not serve directly as executable or browsable content. Place the storage path outside the application and static roots, set ownership so only the CKAN process can write to it, and check that the web server cannot run scripts from that location. Test by uploading a file and requesting its URL directly.
Extension routes and settings review
Third-party extensions can add routes, API actions and configuration options that bypass the controls you set for core CKAN. Inventory every installed extension, list the routes and actions it registers, and confirm which ones require authentication or admin rights. Review extension settings for anything that enables unauthenticated access or broad permissions, and treat unmaintained extensions as a risk to resolve before go-live.
How to test that the hardened portal fails safely
The purpose of this section is to prove that each hardening control refuses the action it is meant to block, and that it does so in a way your team can see afterwards. A control that has only been configured has not been shown to work. For a CKAN portal, the test plan should cover the DataStore database role, the network reach of Solr and Redis, API token and admin access, upload handling, and web server disclosure. Write one test case per control, with the exact request or command, the expected refusal, and the evidence you will keep.
Start with the DataStore. The read-only database user should be refused on INSERT, UPDATE and DELETE statements run against DataStore tables, using the same connection details the portal uses. The test is only half done if those writes fail. Also run the queries the Data API needs, such as the SELECT statements behind filtering, search and pagination, and confirm they succeed. If the read-only role cannot run the Data API queries, the portal will look broken to users and someone will be tempted to grant write access back. Record the role name, the statements tried, and the error returned for each refused write.
Next, test network exposure from outside the CKAN network segment. Attempt connections to Solr and Redis from a host that is not a CKAN component, using the ports those services listen on. Both should refuse or time out. Repeat the check from the public side for the web tier. For API tokens, use a token that has expired and one that has been revoked, and confirm the portal refuses both. Then send requests with no credentials to administrative routes and confirm they are refused. Confirm your team knows which CKAN role should be able to reach these routes, so the expected result is written down before the test runs.
Upload limits need two tests: an oversized file and a file of an unexpected type. Both should be rejected before the file is stored or passed to XLoader, and the rejection should not leave a partial resource record behind. Confirm the size and type limits you configured match the written policy, and check the web server limit as well as the application limit, since either can stop the request first. The web server test also covers disclosure. Request an unknown path and confirm the response does not show a server version banner, and request a directory path to confirm directory listings are off. Ask your web server and CKAN administrators to confirm which settings govern each result.
Run all of these checks against staging first, using a build that matches production. Keep the outputs as evidence: the command, the timestamp, the response, and the log line produced. Apply one rule to every test. A failed control must fail closed, meaning the request is refused rather than allowed through, and it must produce a log entry that an operator can find. If a test fails open or leaves no log, treat it as a defect and retest after the fix. Store the results with the configuration version so an auditor or your own review can match each result to the settings that produced it.
What buyers ask before hiring help with CKAN hardening
How much does CKAN security hardening cost?
DeployOpen does not publish a price list, and a quote follows from the written scope. The main cost drivers are the number of CKAN instances and environments, how many third-party extensions need a security review, how deep the configuration and hardening checks go, and whether you want a retainer for patch work after the initial hardening. The initial hardening is a one-time engagement. A patch retainer recurs, so ask each quote to separate the one-time work from any ongoing monthly or annual fees. When you request a quote, ask for the scope list, the deliverables, the environments covered, and the assumptions about access and your staff time.
How long does CKAN hardening take?
Duration depends on the same drivers that set cost: the number of instances, the size and age of your extension set, how many environments must be brought to the same standard, and how much of the portal runs in your own infrastructure versus a managed setup. A single production instance with a small, well-known extension set takes far less time than a multi-instance portal with custom extensions and several Solr or Redis nodes. DeployOpen agrees a timeline in the written scope before work starts, so ask for the timeline as part of the quote and check which tasks depend on your change windows and approvals.
Can our in-house team harden CKAN without a partner?
Yes, many teams can, provided they have people who understand CKAN's architecture, the PostgreSQL and DataStore setup, Solr and Redis exposure, and the web server layer. The work touches the DataStore read-only database user, API token handling, upload processing, and the review of third-party extensions, so the team needs hands-on Linux, database and application security skills. Be realistic about capacity: the team must also keep the portal running and apply patch releases. Ask yourself whether you can staff a repeatable patch cycle, since a hardened configuration drifts quickly after an unpatched release. A partner is most useful when you lack these skills or need an independent review.
What access and environments does a hardening partner need?
The partner needs controlled access to the environments in scope, typically staging or a copy of production, plus read access to configuration, deployment code and logs. Access should run in your cloud accounts, data centers or private network, and DeployOpen works inside your own infrastructure rather than hosting the portal. Ask for a named access list, a secure channel for credentials, and a clear rule on production changes. Confirm which systems are out of scope, such as identity providers, hosting platforms or backup vaults, and who owns decisions on configuration changes, extension removals and maintenance windows.
Does CKAN hardening replace a penetration test?
No. Hardening changes the configuration and the way the portal is built and run, while a penetration test independently tries to find and exploit weaknesses in the deployed system. The two answer different questions, so they should be scoped separately. DeployOpen runs security testing as its own service, and a test should ideally come after hardening so the findings reflect the hardened state. Ask any provider to define the testing depth, the targets, the rules of engagement and the retest terms in a separate written scope.
Is compliance certification included in CKAN hardening?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, so your auditor has material to review. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments and issue the reports. Before you start, ask which framework applies to your portal, which controls the hardening work maps to, and which evidence your auditor expects to see, such as patch records, configuration baselines and access logs.
Why do third-party extensions change the hardening scope?
Each installed extension adds code, dependencies, routes and sometimes database access, so every extension you run can change the attack surface. A review checks what each extension exposes, how it handles uploads and user input, which versions it pins, and whether it is still maintained for your CKAN version. Extensions such as ckanext-dcat or ckanext-saml2auth need the same review as custom code. Ask for the list of installed extensions, their versions and their sources as the first step, because the count and complexity of that list strongly affect effort.
Keeping the hardened baseline after go-live
Hardening is only as good as the work that keeps it in place after go-live. The recurring tasks are patching, extension review, token hygiene, access list review for Solr and Redis, and confirming that the DataStore read-only role still matches the schema. Plan these as scheduled checks with named owners, not as a one-off project closeout item.
Patching comes first. CKAN's release policy supports the latest patch of the current minor version and the previous minor version, and an older patch loses support once a newer one is out. Patch releases are meant to avoid backwards-incompatible changes and schema changes, but minor releases can contain incompatible changes. Agree a patch cadence with your team, record each patch applied in a patch log, and treat any minor version move as a planned upgrade with its own test cycle. Confirm the current support window with the CKAN release documentation before you set the cadence.
Every upgrade, and every extension installed, updated or removed, changes the attack surface. After each change, re-review the affected extensions for compatibility with the CKAN version in use, check their configuration against the baseline, and confirm that authentication, authorization and upload handling still behave as documented. Extensions such as ckanext-saml2auth touch sign-in and role assignment, so a change there should trigger a repeat of the identity and access checks, not only a smoke test of the portal.
API tokens and infrastructure access need periodic attention. Review the token policy: who holds tokens, which lifetimes apply, and how stale or unused tokens are revoked or expired. For Solr and Redis, review the access lists and network rules against what the portal actually connects to, since a change in hosting or an added service can quietly widen exposure. Confirm that the DataStore read-only user still has only the grants it needs and that those grants match the current schema after new resources or tables were added.
Document everything the checks rely on: the configuration baseline, the list of installed extensions with their versions, the token policy, the patch log and the verification results from each review. Keep these records with the change history so that an auditor or incident responder can see what was true on a given date. DeployOpen can run this cycle as a retainer for ongoing support and continuous testing, with the scope, cadence and reporting agreed in writing. When you request a quote, ask what the retainer covers, which checks run after each upgrade, and how re-testing after an extension change is billed.
How DeployOpen works on this
DeployOpen plans, hardens, documents and supports self-hosted CKAN portals inside your own cloud accounts, data centers or air-gapped networks. Each engagement starts from a written, fixed scope that names the hardening areas, the systems in play and the evidence you will receive.
How we scope
- Inventory the CKAN version, installed extensions, Solr, Redis and PostgreSQL versions, and where each component runs.
- Agree a written patch policy that matches the CKAN release policy and names who applies patch releases and how fast.
- Confirm which areas are in scope: DataStore read-only user, Solr and Redis exposure, API tokens, uploads, web server and third-party extensions.
How we build
- Configure the DataStore read-only database user separately from the write user, and verify that the Data API cannot write through it.
- Restrict network access to Solr and Redis, then test that they are unreachable from outside the application tier.
- Review upload handling, API token lifetimes and Nginx and uWSGI settings, and test each change against a staging copy before production.
How we hand over
- Deliver a configuration record and runbook covering each hardening decision, its reason and how to verify it.
- Provide test results from the security testing performed on the portal, with findings, fixes and any accepted residual risk.
- Walk your platform and security staff through patching, token rotation and extension review so the portal can be run in-house.
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
- Confirm with us in the quote what a retainer covers for patch application, extension compatibility checks and re-testing after upgrades.
- Ask for a clear list of what is excluded, such as your own policies, audits or third-party assessments, which remain your responsibility.
