Blog · Licence guides
Security patches and client delay
Updated 5 September 2026 · Based on our Software Licence & Services model
When LMS White notifies you of a material security fix, timely access matters — delay or refusal can shift responsibility for resulting loss.
What this means for you
If LMS White identifies a material security issue in proprietary code and a Corrective Fix, configuration change or Version Upgrade is appropriate, we may notify your designated technical/security contact.
You should provide timely authorisation and access. For critical issues, act as soon as reasonably practicable; for high-severity issues, do not unreasonably delay beyond the next available maintenance window. If you refuse or prevent installation after notice, LMS White is not responsible for loss to the extent caused by that delay.
Older versions may be designated end-of-life. If a free Version Upgrade to a Supported Version is available but you stay on EOL, Corrective Fixes for that EOL version may stop after reasonable notice.
Why patch timing is shared responsibility
Vendors can ship fixes; only the account owner can approve production access. Holding a known critical patch “until next year” is a classic cause of preventable incidents across the industry — which is why agreements allocate delay risk to the party that blocked installation.
Examples
- Critical auth fix ready → you grant Firebase access within days → fix ships.
- Notice sent; access refused for months → resulting exploit tied to the unpatched issue falls outside LMS White delay liability.
What LMS White does: notify and supply appropriate Corrective Fixes / upgrades for Supported Versions.
What you do: keep a reachable security contact and approve access so fixes can be installed.