GLPI security hardening starts with where the web root points
Hardening a GLPI server means controlling what the web server exposes, where secrets are stored, who can sign in, and how sessions, API calls and plugins are governed and kept current. The first and most consequential decision is the document root. GLPI's installation documentation requires the web server's document root to point to the application's public directory rather than the installation root, with URL rewriting routing requests through index.php. That applies whether you run Apache, Nginx, lighttpd or IIS. If the root points at the installation directory, files such as configuration and key material can sit inside the path a browser can reach.
Confirm this before anything else. Request the server's virtual host or site configuration and check that the document root resolves to the public directory. Then try to request files outside it, including the config directory and the key files, and confirm the server refuses them. Do the same check after every change to the web server, including a PHP version change, because a rewritten or copied vhost can quietly undo the setting. Record the result as evidence for your own change process.
Hardening is harder than it looks because GLPI runs its own permission model on top of the web server. The web server decides who can reach a path, but GLPI decides which profile, entity and right applies to each ticket, asset or administrative function. Those two layers need to be reviewed separately. Keys are a second trap. The glpi.key and glpicrypt.key files protect encrypted data, and the update procedure requires backing them up alongside the database and files. Lose or mismatch them and a restore may not decrypt what it recovers, so key handling belongs in the same runbook as backups.
Plugins are the third trap. Each plugin can add pages, API endpoints and database changes, so it changes the attack surface in ways the core product does not. GLPI 11.0 suspends plugins when a new version is detected and requires reactivation after major updates, which means plugin review belongs in every upgrade plan. Ask your team and any integrator to list every installed plugin, its source and its owner, and to confirm which versions are supported on the GLPI release you run.
GLPI is distributed under the GNU General Public License version 3 and maintained by Teclib'. The license gives you the right to run and modify the software, but it does not transfer responsibility for the server. Hardening, patching, backups and access control sit with the operator of the server, whether that is your team or a partner you engage. Decide that ownership in writing before go-live.
Which hardening choices fit your GLPI deployment
This table compares the main hardening decisions for a GLPI server: web server layout, key storage, authentication order, target version and plugin policy. Read each row for the conditions where the option fits and the ongoing work it adds, then choose the combination your team can operate and patch on schedule.
| Decision | Option | When it fits | Operational cost |
|---|---|---|---|
| Web server layout | Bare metal Apache, Nginx, lighttpd or IIS with document root on the public directory | Your team already runs and patches this web server and PHP stack | Document root and URL rewriting must be kept correct through every OS and PHP package update |
| Web server layout | Official GLPI Docker image | You standardize on container hosting and want image-based rebuilds | Image pulls, volume mapping for config and files, and a defined process for rebuilding after each release |
| Key storage | Keep glpi.key and glpicrypt.key in the config directory with restricted file permissions | Single-server deployments managed by a small admin group | Both keys must go into every backup set alongside the database, and restores must be tested with them |
| Key storage | Move the config directory outside the web root and restrict access to the service account and named admins | You need tighter separation between web-readable files and secrets | Path changes must be confirmed against the installation docs for your version and repeated after each upgrade |
| Authentication order | Database accounts first, then LDAP, IMAP or REMOTE_USER | You need local accounts for break-glass access while directory sign-in handles daily use | Two password policies to maintain, and local accounts still need MFA or strict lockout rules where possible |
| Authentication order | Directory or REMOTE_USER sign-in with one sealed local admin account | Central identity is the system of record and access reviews run from the directory | Depends on directory and reverse proxy availability, plus a tested recovery procedure for the sealed account |
| Target version | GLPI 12 for session review, session revocation and step-up authentication on certain admin actions | You can meet the PHP 8.3 and MariaDB 10.11 prerequisites and plugins are confirmed compatible | Staging upgrade, db:update, backup of keys, and plugin reactivation after the major update |
| Target version | Stay on GLPI 11 for now and track its patch releases | Key plugins or integrations are not yet confirmed on GLPI 12 | Session controls from GLPI 12 are unavailable, and a later migration still needs its own test cycle |
| Plugin policy | Marketplace plugins only, with version pinning and a review of each update | You want vendor-maintained code and a predictable update path | Each new version needs compatibility checks, and plugins may be suspended until reactivated after a major update |
How to harden a GLPI server in the right order
This sequence takes a GLPI server from a default install to a hardened state in an order that protects the encryption keys and configuration before anything else changes. Each step closes with a check the reader can run, so the team knows the control works before moving on.
Point the web server at the public directory
Configure Apache, Nginx, lighttpd or IIS so the document root is GLPI's public directory rather than the installation root, and enable URL rewriting so every request is routed through index.php. The web server administrator makes this change, and the GLPI installation docs describe the expected layout for each server type. The step is complete when the login page loads at the site root and a request for a PHP file outside the public directory returns a denial or a 404 rather than the file contents.
Block direct access to the installation root
Confirm that no path outside the public directory can be reached over HTTP, including source files, the vendor directory, plugin code and logs. If the web server is not yet configured to refuse these paths, add explicit deny rules before going further. The check is a set of direct HTTP requests to known application and config file paths, each of which must return a denial. Record the responses so the same test can be repeated after every update.
Move keys and config outside the web root
Relocate glpi.key, glpicrypt.key and the configuration files to a directory outside the web root, then point GLPI to the new locations through its configured paths. Set file ownership so only the web service account and the administrator can read them, and remove world-readable permissions. The check is an HTTP request for each key and config file, which must return a denial, plus a confirmed read by the application account after the move. Keep a copy of both key files in the backup set described in the final step.
Set the authentication order and local account policy
Review the authentication sources in the order GLPI tries them: the internal database, LDAP directories, IMAP servers and external methods such as REMOTE_USER. Decide whether local accounts should remain for break-glass use, and restrict or disable the rest once directory sign-in is confirmed. The administrator tests each source with a known account and documents which account can still sign in without the directory. The step is complete when a disabled or excluded account is refused and a break-glass account is tested and recorded.
Configure password, session and step-up policy
Set password complexity, lockout and session timeout values to match your identity policy, then review the GLPI 12 active session view so administrators can see and revoke sessions. Enable step-up authentication for the administrative actions your version supports, and confirm the list of actions in the release notes for the version you run. The check is a test administrator session: sign in, perform a protected action, confirm the second check is requested, and revoke a session from another browser to confirm it ends.
Restrict API clients and access
Review which API clients and tokens exist, retire any that are unused, and limit the remaining clients to the IP ranges and user profiles they need. Confirm that the API is only reachable over HTTPS on the paths intended for it. The check is an unauthenticated API request, which must be refused, and an authenticated request from an unlisted address, which must also be refused. Document the owner of each client so that revocation is possible when a service changes.
Review plugins and suspend unused ones
List every installed plugin, its publisher and its version, and compare each one against a current business need. Suspend or remove plugins that no longer serve a purpose, since each one adds code that must be patched. Since GLPI 11.0, plugins are suspended when a new version is detected, so plan to reactivate and test the remaining plugins after each major update. The check is a written inventory with one decision per plugin and a confirmed list of active plugins.
Confirm a full backup before any patch
Before applying any update, confirm a current backup of the database, the application files and the config directory, including glpi.key and glpicrypt.key. The installation docs require this set before the update procedure starts, and a restore should be tested on a separate copy at least once. The check is a restore of the backup to a staging environment, after which GLPI starts and the key-protected data can be read. Only then proceed to replacing application files and running the database update.
How hardening differs on bare metal, reverse proxies and Docker
When Apache, Nginx, lighttpd or IIS serves GLPI directly, the web server itself is the first control point. GLPI's installation documentation requires the document root to point to the public directory inside the installation, not to the installation root, and it requires URL rewriting so requests route through index.php. If the document root is wrong, files such as configuration and key material can be reachable over HTTP, so this setting is the most important check in this shape.
What to check on this host:
- Document root: confirm it points to the public directory in the server block or site definition for your exact GLPI version.
- URL rewriting: confirm the rewrite rules that route requests through index.php are present and match the vendor example for your web server.
- Denied paths: confirm that the config directory, the files directory and the key files are not served directly, and test this with a request from outside the host.
- TLS and headers: TLS, HSTS and other response headers are configured here because nothing sits in front of the server.
- Client identity: REMOTE_USER authentication should stay disabled unless a trusted layer sets it, because the server itself has no way to verify the value.
Before go-live, ask the vendor documentation for your GLPI version to confirm the public directory name and the rewrite rules, and test the result rather than assuming the layout from an earlier release.
When a reverse proxy terminates TLS and forwards requests to GLPI, the proxy becomes part of the security boundary. The controls on the GLPI host still apply, including the document root, but the proxy adds its own rules for certificates, headers and client identity. GLPI can trust a user identity passed in REMOTE_USER only when the proxy is the only path to GLPI and the proxy strips any identity header sent by the client.
What changes in this shape:
- TLS termination: the proxy holds the certificate and cipher configuration, so GLPI's own TLS settings must be checked at the proxy, not the application.
- Forwarded headers: confirm which forwarded headers GLPI and the proxy trust, and make sure the client cannot set them directly.
- Direct access: the GLPI host should accept connections only from the proxy, so a client cannot bypass the proxy and send a forged REMOTE_USER value.
- Identity pass-through: enable REMOTE_USER only when the proxy authenticates the user and strips any incoming value of that header.
- Logging: the client address in GLPI logs may be the proxy address unless forwarded headers are configured correctly, which affects login investigations.
Confirm with the vendor documentation for your GLPI version how REMOTE_USER is handled and which header and trusted address settings it expects. Do not assume the proxy configuration from another application carries over.
The official GLPI Docker image is among the distribution options listed for GLPI 12.0.0. In this shape, the image layout, the mounted volumes and the container's network exposure decide what is protected. Files that are normally outside the web root on a bare metal install may sit in a different path inside the container, and the keys and configuration must persist across container replacements, which means they are mounted from the host.
What to check in a container deployment:
- Image layout: confirm from the image documentation for 12.0.0 where the public directory, the configuration and the files directory sit inside the container.
- Key and config mounts: confirm that glpi.key and the config directory are mounted from storage with restricted permissions, and that they are not baked into the image or copied into a public path.
- Volume permissions: check the ownership and mode of mounted paths so the web process can read what it needs and nothing else can.
- Network exposure: publish only the port the proxy or load balancer needs, and confirm that the database port is not published to the host or to other networks.
- Image provenance and updates: pin the image tag, record the digest, and plan rebuilds when the image is updated.
Confirm each of these points with the vendor's Docker documentation for the specific version. Container layouts change between releases, so do not reuse paths or volume names from another version or from a community image.
GLPI 12 session and step-up controls and what they do not replace
These cards cover the GLPI 12 session, sign-in, password, API and key controls that reduce risk inside the application. They do not replace network segmentation, TLS configuration, patching or review of custom code and plugins, which remain separate controls. Confirm the exact options in the GLPI documentation for your installed version before relying on them.
Active session review and revocation
The GLPI 12.0.0 release notes list a view of active user sessions with the ability to revoke them. Use it during access reviews, after role changes and when account misuse is suspected. Confirm which profiles can open this view, how long sessions last by default, and whether revoking a session also ends API or REMOTE_USER sessions. Test revocation on a staging copy with a test account so the response procedure is known before an incident.
Step-up authentication for administrative actions
GLPI 12.0.0 adds step-up authentication for certain administrative actions, which asks a signed-in administrator to confirm identity before a sensitive change. Build a written list of the actions that trigger it in your version and test each one with an administrator account and a lower-privilege account. Check how the prompt behaves under SSO or REMOTE_USER, where the identity provider may need to handle re-authentication. Record the list in your change procedures.
Authentication order and enabled sources
The GLPI user documentation describes authentication against the internal database, then LDAP directories, then IMAP servers, then other external methods such as REMOTE_USER, tried in that order. Review which sources are enabled, since each one adds a path into the application. Disable unused sources, and confirm how a user name that exists in more than one source is resolved. Keep one documented break-glass administrator in a controlled source, with its access logged and reviewed.
Password policy settings to set and confirm
The operator must set the password policy in GLPI and confirm the values for the installed version, because option names and defaults can change between releases. Agree minimum length, complexity, expiry, lockout and reuse rules with the security team before go-live. Confirm whether the policy covers only local accounts or also reaches users who sign in through LDAP or IMAP, where the directory usually controls the password. Verify each setting on a staging copy.
API access control and client restrictions
Review whether the REST API is enabled, which clients may call it and how API tokens are issued and tied to user profiles. Restrict clients by address or application where your GLPI version supports it, and remove tokens for retired integrations on a set schedule. Confirm each option in the documentation for your version. Then test with a low-privilege account to show that the API does not return data the web interface hides from that profile.
Protecting glpi.key and glpicrypt.key
The glpi.key and glpicrypt.key files hold encryption material that GLPI uses, and the update procedure requires backing up the config directory that contains them. Keep them outside the public web root, restrict read access to the web service account and administrators, and keep backups encrypted and access-controlled. Do not store copies in shared repositories or tickets. Include them in restore tests, because losing them can leave encrypted data unreadable.
How to verify GLPI hardening works and fails safely
Verification should show that each control fails closed, so a broken setting produces a denial and never exposes content. Start from outside the network with no session, then work inward. Request the configuration directory, the installation root and the key files glpi.key and glpicrypt.key directly from a browser and from a command line client. Each request should return a denial or a not found response, never file contents. Then request the public directory and index.php, which should load the normal login page. Because rewrite rules differ between Apache, Nginx, lighttpd and IIS, confirm the exact paths against your own web server configuration and keep the responses with timestamps as evidence for your assessor.
Next, test the session and administrative controls in GLPI 12. Sign in with a test account in one browser, then revoke that session from the active session view using an administrator account. The first request from the revoked browser should send the user back to sign in. For step-up authentication, sign in as an administrator and attempt each action on your agreed list, such as changing authentication settings, managing accounts or altering API configuration. A re-authentication prompt should appear before the change saves. Also test a wrong password for a directory user and confirm it does not succeed through a local database account with the same name. GLPI tries database, LDAP, IMAP and REMOTE_USER in that order, so check whether an unmatched name can fall through to an unintended account.
Test API access and plugin state next. Call the REST API with no token, with an invalid token and with a token from a client that is not on your approved list. Each call should be refused. Confirm that accounts which do not need API access cannot use it at all. For plugins, run a test update in a staging copy. GLPI 11 and later suspend plugins when it detects a new version, so confirm that a suspended plugin stays inactive until a named reviewer checks its compatibility and reactivates it deliberately. Compare the active plugin list with your approved inventory and record any difference as a finding to resolve before go-live.
The restore test confirms that the backup can recover the system. Restore a copy of the backup into a separate environment, never the production server. Before anything else, confirm that glpi.key and glpicrypt.key are present in the restored configuration directory. The GLPI update procedure treats these files as part of the backup set, and a database backup without them cannot be used to recover encrypted data. After the restore, sign in, open a sample of tickets, assets and attached files, and confirm they match production. Write down the steps and any gaps so the team can repeat the test on a schedule.
Internal checks show what your team configured, but they do not show what an outside tester can reach. Commission an external scan or penetration test as a separate engagement with written scope and rules of engagement covering the web application, the API and the server. DeployOpen runs security testing for applications, APIs and infrastructure as a service, with the scope agreed in writing before work starts. Testing findings are evidence for your own review, and DeployOpen does not issue audit reports. Ask your independent auditor or certification body what evidence they expect from testing.
What drives the effort and cost of GLPI hardening
This table compares the factors that change how much work a GLPI hardening engagement involves, and what each one costs in effort. Read each row as a lever: the first column names the driver, the second explains why it matters, and the third shows how to keep it under control before work starts.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Web nodes and environments | Each production, staging and test copy needs the same document root, PHP settings, file permissions and session settings checked and verified. | Keep fewer environments and define the configuration as code so one reviewed baseline is applied everywhere. |
| External authentication sources | Each LDAP directory, IMAP server or REMOTE_USER path adds connection settings, certificate handling, failover behavior and account-mapping tests. | Confirm which sources are needed at go-live and retire unused ones before the hardening scope is written. |
| Marketplace and custom plugins | Every installed plugin needs a code review, a check of its file access and database changes, and retesting after each GLPI update. | Reduce the plugin list to business-critical items and agree in writing which plugins are reviewed and which are removed. |
| API consumers and integrations | Each API client needs its own credentials, token scope, IP restrictions and logging, and each integration must be tested against the hardened settings. | Inventory every consumer first, limit access to the endpoints each one uses, and retire clients that no longer run. |
| Depth of compliance evidence | Assessors may ask for configuration exports, change records, access reviews and test results, and each artifact must be collected and dated. | Agree the control list and evidence format up front, and confirm with your assessor which artifacts they expect. |
| Internal web server and PHP skills | Where in-house staff already run Apache or Nginx and PHP-FPM, less knowledge transfer is needed. Gaps add training and review time. | Name the internal owners before kickoff and ask for a handover session and written runbooks as part of the fixed scope. |
What to monitor, back up, patch and document after hardening
Hardening only holds if you can see when controls are tested or bypassed. Forward web server access and error logs from the GLPI host to the log platform your security team already reviews, and focus on events that show someone probing the application instead of using it. Confirm where your GLPI version writes its own application logs, because locations and file names depend on the installation and configuration.
- Denied requests to protected paths: Requests to configuration, key or internal directories that the web server should refuse. Alert on repeated attempts from one source address.
- Failed sign-ins: Failures per account and per source address. Because GLPI tries authentication methods in a fixed order, a failure may originate in the internal database, a directory service or an external method, so log the method where possible.
- Session revocations: GLPI 12.0.0 includes a view of active user sessions with the ability to revoke them. Record each revocation, the administrator who performed it and the reason.
- API errors: Authentication failures and unusual request volume against the REST API, compared with the clients you expect to call it.
Check that each alert has a named owner, that notifications reach that owner outside business hours if your service levels require it, and that you have tested at least one alert per category before accepting the hardening work.
A GLPI backup has three parts, and all three are needed to bring the platform back to a working state. The database holds tickets, assets and users. The files directory holds attachments and documents. The config directory holds the settings files and the two keys, glpi.key and glpicrypt.key. Losing the keys can leave encrypted values stored in the database unreadable, so treat the config directory as sensitive material, not as ordinary configuration.
- Database: Take a consistent dump using a method your database team has validated for MariaDB or MySQL, with the application quiesced or with a transaction-consistent option.
- Files: Back up the documents and attachments directory. Confirm its location in your configuration, since it may sit outside the application directory.
- Config directory and keys: Copy glpi.key and glpicrypt.key with the rest of the config directory. Store these copies separately from the database backup and restrict access, because a database copy plus the keys can expose protected values.
- Restore test: Restore to a separate host on a fixed schedule, sign in, open a ticket, an asset and an attachment, and confirm that stored credentials for integrations still work.
Check that the restore test produces a written record with the date, the backup used, the person who ran it and the result, because that record is what an assessor or incident responder will ask to see.
Patching GLPI follows the update procedure in the installation documentation: back up first, replace the application files, then run php bin/console db:update. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates. Treat reactivation as a security review, not a formality, because a plugin that worked on the previous version may not be the version you now want running.
- Back up first: Complete the database, files and config backup, including both keys, before any file is replaced.
- Replace application files: After replacement, confirm the web server still points the document root at the public directory and that URL rewriting still works.
- Run the database update: Execute php bin/console db:update from the installation and keep the output with the change record.
- Reactivate plugins with review: Check each plugin's current version, source and permissions, and disable any plugin nobody still needs before reactivating the rest.
- Track release history: GLPI 11.0.11 was released on October 1, 2026, and GLPI 12.0.0 on October 7, 2026, according to the GitHub releases page. Confirm the target version and its prerequisites against the release notes before scheduling.
Check that each upgrade has a rollback plan tested on a staging copy. The full upgrade path between major versions is covered on the GLPI upgrades and support page.
Documentation turns hardening into something a second engineer, an auditor or an incident responder can verify without asking the person who built the platform. Keep these records in a controlled location, update them whenever a setting, key location or plugin changes, and record who approved each change. Records that are not reviewed on a schedule usually stop matching the running system within a few upgrade cycles.
- Hardening baseline: The applied settings, including document root, file permissions, session settings, password policy and API access, with the date and approver for each.
- Key custody record: Where glpi.key and glpicrypt.key are stored, who can access them, where backup copies sit and the date each copy was last verified.
- Authentication order: The methods enabled and the order in which GLPI tries them, based on the documented sequence of internal database, LDAP directory, IMAP and external methods such as REMOTE_USER.
- Plugin inventory: Each plugin's name, version, source, business owner, purpose and last security review.
- Review dates: The next review date for every record, aligned with the release checks in your upgrade process.
Check that every record names an owner and that someone outside the platform team can locate it during an assessment. Confirm with your auditor which evidence formats they accept before you standardize the templates.
How much does GLPI security hardening cost and how long does it take?
What determines the cost of GLPI security hardening?
The cost follows the size and shape of the scope, not a fixed package. The main drivers are the number of GLPI instances and environments (production, staging, test), the number of installed plugins and how many of them need review or replacement, the authentication sources configured (internal database, LDAP or Active Directory, IMAP, or external methods such as REMOTE_USER), the web server and database platforms in use, and whether the hardening covers only the application or also the operating system, reverse proxy and backup chain. Each added environment or authentication source adds configuration and verification work. DeployOpen does not publish a price list. A quote follows from a written scope that lists these items, so ask for the scope assumptions to be stated in the quote.
How long does a GLPI hardening engagement usually take?
Duration depends on the same drivers as cost, plus your change calendar. A single production instance with few plugins and one authentication source takes less time than a multi-environment deployment with several plugins and LDAP plus REMOTE_USER. Client-side waiting often dominates: approval of a change window, access to servers and the time needed for owners to confirm key and identity decisions. Fixed-scope engagements agree timelines in writing before work starts. Ask the partner to show the phases, the dependencies on your team and the validation steps on a test copy, and to confirm which items depend on a change window.
Can our own team harden GLPI without an outside partner?
Yes, if your team has the skills and time to verify each change. The work touches several layers: the web server, where the document root must point to GLPI's public directory with URL rewriting through index.php; PHP settings and file permissions; the database account and its privileges; protection of glpi.key and the config files; identity and password policy settings; and API access control. Internal staff need working knowledge of Apache, Nginx, lighttpd or IIS, PHP 8.2 or later for GLPI 11, MySQL or MariaDB administration, and key and secret handling. A partner adds value mainly through a documented baseline, a test copy with before and after evidence, and a second reviewer for plugin and API exposure.
What do we need to provide for a GLPI hardening project?
Four inputs decide whether the work can proceed on schedule. First, access to the GLPI servers, the web server, the database and the backup systems, under your access rules. Second, an approved change window for production changes, since several controls require a restart or a service reload. Third, named owners for the glpi.key and glpicrypt.key files and for each identity source, including the people who approve LDAP bind accounts and profile mapping. Fourth, a test copy of GLPI with a current database and files, so that changes are verified before production. Without a test copy, the verification step cannot be completed safely.
What does a fixed-scope GLPI hardening review include?
A fixed-scope review produces a documented gap assessment, agreed changes and verification evidence. Typical elements are: a configuration review of the web server, PHP, database and GLPI settings against the hardening items listed above; a plugin inventory with a decision for each plugin; a review of authentication sources, password policy and API access; a change plan with rollback steps; implementation on a test copy; and a report showing what changed and how it was checked. The exact deliverables, environments and exclusions are set out in the written scope before work starts. Ask for a sample deliverable and a list of items not covered, such as penetration testing, which is a separate service.
Does GLPI 12 change the hardening work?
Yes, GLPI 12 adds controls to review and changes the upgrade sequence. The GLPI 12.0.0 release notes list a view of active user sessions with the ability to revoke them, and step-up authentication for certain administrative actions. These should be configured and tested as part of the hardening baseline, along with the new knowledge base and access settings. The official Docker image is another distribution option that changes how files, the document root and keys are placed. GLPI 12 also requires PHP 8.3 or later and MariaDB 10.11 or later or MySQL 8.0 or later according to the GLPI README, so confirm the platform versions on a staging copy before planning the move.
Will GLPI security hardening make us compliant with a standard or regulation?
Hardening supports compliance readiness but does not create compliance. It reduces exposure in the GLPI platform and produces configuration evidence that assessors often ask for. DeployOpen prepares controls, settings and evidence for compliance assessments. Independent auditors and certification bodies issue any audit report, attestation or certification. Ask your assessor early which evidence they expect from the GLPI platform, and confirm with them how the control scope maps to your own policies before the work is scoped.
How DeployOpen scopes, hardens and hands over GLPI
DeployOpen plans, implements, hardens, documents and supports self-hosted GLPI inside infrastructure you control, including your cloud accounts, data centers or air-gapped networks. Each engagement starts from a written, fixed scope so the security work, its deliverables and its timeline are agreed before changes begin.
How we scope
- Confirm the GLPI version, PHP and MariaDB or MySQL versions, and the web server in use before any hardening starts.
- Map where glpi.key, glpicrypt.key and config files sit, and who can read them on the host.
- Agree in writing which controls are in scope, such as document root placement, password policy, API access, plugin review and patching.
How we build
- Point the web server document root at GLPI's public directory with URL rewriting to index.php, then verify direct access to other paths is blocked.
- Restrict file permissions on encryption keys and configuration so only the application and administrators can reach them.
- Configure session, step-up authentication and API client settings, testing each administrative path and API endpoint against the agreed scope.
How we hand over
- Deliver a written record of each hardening change, its reason, and the test that confirmed it on your environment.
- Document the key backup procedure and the update steps, including the db:update run and plugin reactivation after major versions.
- Walk your administrators through the settings, plugin decisions and the checks they should repeat after each GLPI update.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after go-live, agreed in a separate written scope.
- Re-test hardening settings after each GLPI or PHP update, since configuration drift can reopen gaps.
- Ask any provider to confirm which controls they prepare evidence for, since DeployOpen prepares evidence but auditors and certification bodies issue reports.
