{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"security/patch-management","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/security/patch-management/","da":"https://cmaintz.github.io/tech-atlas/da/terms/security/patch-management/"},"term":{"en":"Patch management","da":"Patch management"},"aka":{"en":["update management"],"da":["opdateringsstyring","patchstyring"]},"domain":["security"],"cluster":"controls","layer":"host","status":"current","summary":{"en":"The routine of keeping all software up to date so that known weaknesses are closed before attackers use them.","da":"Rutinen med at holde al software opdateret, så kendte svagheder lukkes, før angribere udnytter dem."},"body":{"formal":{"en":"The repeated process of finding out which patches exist for the organisation's software, ranking them by risk, testing them, installing them within a set time and confirming they took effect.","da":"Den gentagne proces med at finde ud af, hvilke patches der findes til virksomhedens software, prioritere dem efter risiko, teste dem, installere dem inden for en fast frist og bekræfte, at de virker."},"plain":{"en":"Like a car recall - the fault is known and a fix exists, but it only helps once each car is actually brought in.","da":"Som når en bilfabrik kalder biler tilbage - fejlen er kendt, og der findes en løsning, men den hjælper først, når hver bil faktisk kommer ind."},"inPractice":{"en":"A serious weakness in the VPN used by a pension fund is announced on Tuesday; the IT operations manager tests the fix that night and has every VPN device updated by Thursday, as the fund's 72-hour rule demands.","da":"En alvorlig svaghed i den VPN, en pensionskasse bruger, offentliggøres tirsdag; den IT-driftsansvarlige tester rettelsen samme aften og har opdateret alle VPN-enheder torsdag, som pensionskassens 72-timersregel kræver."},"whyItMatters":{"en":"Once a weakness is made public, attackers race to use it; many real attacks, including ransomware, succeed simply because a fix was available but never installed.","da":"Når en svaghed bliver offentlig, skynder angribere sig at udnytte den; mange reelle angreb, også ransomware, lykkes blot fordi en rettelse fandtes, men aldrig blev installeret."}},"deepDive":{"en":"NIST SP 800-40 Rev. 4 (2022) reframes patching as preventive maintenance and recommends that organisations define a small number of maintenance plans by asset type and risk rather than treat each patch as a project. It distinguishes routine patching on a regular cadence from emergency patching for vulnerabilities that are actively exploited or critical on exposed systems, and adds two alternatives when no patch can be applied: mitigation (configuration changes, virtual patching at an IPS or WAF, isolation) and risk acceptance with a documented owner and expiry. A patch cycle typically runs: intake from vendor advisories and vulnerability feeds, applicability matching against the asset and software inventory, prioritisation, testing, staged deployment in rings (a pilot group, then broad deployment), verification, and exception handling.\n\nPrioritisation has moved beyond CVSS base scores, which describe technical severity but not likelihood. Common inputs now include CISA's Known Exploited Vulnerabilities (KEV) catalogue, which under Binding Operational Directive 22-01 obliges US federal agencies to remediate listed CVEs within set deadlines (two weeks for recent CVEs by default); the Exploit Prediction Scoring System (EPSS) from FIRST, which estimates the probability of exploitation in the next 30 days; internet exposure; and asset criticality. Time-to-exploit for publicised vulnerabilities has fallen to days in many cases, so edge devices - VPN concentrators, firewalls, file-transfer appliances - are generally treated as emergency-class regardless of internal SLAs.\n\nOperational realities complicate the cycle. Microsoft releases security updates on the second Tuesday of each month (Patch Tuesday), but third-party applications, browsers, firmware (BIOS/UEFI, BMC, network devices) and container base images follow their own rhythms. Reboots, maintenance windows and application compatibility create lag; medical and OT systems may be certified only for specific versions and require vendor approval. End-of-life software receives no patches at all and must be isolated or replaced. Tooling is shifting toward cloud-managed services, and Microsoft announced in 2024 that WSUS is deprecated, with no new feature development. In containerised environments the unit of patching is the image: fixes are applied by rebuilding from an updated base and redeploying, not by patching running containers.\n\nMetrics that auditors and boards ask for are coverage (share of assets reporting patch status), mean time to remediate by severity, and SLA compliance, with exceptions tracked explicitly. The control anchors are CIS Controls v8 Control 7 (Safeguards 7.3 and 7.4 on automated OS and application patching), ISO/IEC 27002:2022 control 8.8 (management of technical vulnerabilities) and NIS2 Art. 21(2)(e) on vulnerability handling. Patch management is complementary to vulnerability scanning, which verifies that patches actually landed, and to hardening, which removes components that would otherwise need patching.","da":"NIST SP 800-40 Rev. 4 (2022) omformulerer patching til forebyggende vedligeholdelse og anbefaler, at organisationer definerer et lille antal vedligeholdelsesplaner efter aktivtype og risiko i stedet for at behandle hver patch som et projekt. Den skelner mellem rutinemæssig patching i en fast kadence og nødpatching af sårbarheder, der aktivt udnyttes eller er kritiske på eksponerede systemer, og tilføjer to alternativer, når der ikke kan patches: afbødning (konfigurationsændringer, virtuel patching i en IPS eller WAF, isolering) og risikoaccept med en dokumenteret ejer og udløbsdato. En patchcyklus forløber typisk sådan: indsamling fra leverandørernes sikkerhedsmeddelelser og sårbarhedsfeeds, afstemning af relevans mod aktiv- og softwarefortegnelsen, prioritering, test, trinvis udrulning i ringe (en pilotgruppe, derefter bred udrulning), verifikation og håndtering af undtagelser.\n\nPrioriteringen er rykket ud over CVSS-basisscoren, der beskriver teknisk alvor, men ikke sandsynlighed. Typiske input er nu CISA's katalog over Known Exploited Vulnerabilities (KEV), som under Binding Operational Directive 22-01 forpligter amerikanske føderale myndigheder til at udbedre listede CVE'er inden for faste frister (som udgangspunkt to uger for nyere CVE'er); Exploit Prediction Scoring System (EPSS) fra FIRST, der estimerer sandsynligheden for udnyttelse inden for de næste 30 dage; eksponering mod internettet; og aktivets kritikalitet. Tiden fra offentliggørelse til udnyttelse er i mange tilfælde faldet til dage, så kantudstyr - VPN-koncentratorer, firewalls, filoverførselsappliances - behandles generelt som nødpatching uanset interne frister.\n\nDriftsvirkeligheden komplicerer cyklussen. Microsoft udsender sikkerhedsopdateringer den anden tirsdag i hver måned (Patch Tuesday), men tredjepartsapplikationer, browsere, firmware (BIOS/UEFI, BMC, netværksudstyr) og container-baseimages følger deres egne rytmer. Genstarter, servicevinduer og applikationskompatibilitet skaber forsinkelse; medicoudstyr og OT-systemer er ofte kun certificeret til bestemte versioner og kræver leverandørens godkendelse. End-of-life-software får slet ingen patches og skal isoleres eller udskiftes. Værktøjerne flytter mod cloudstyrede tjenester, og Microsoft meddelte i 2024, at WSUS er udfaset uden ny funktionsudvikling. I containeriserede miljøer er imaget patchenheden: rettelser indføres ved at genbygge fra en opdateret base og udrulle igen, ikke ved at patche kørende containere.\n\nDe nøgletal, revisorer og bestyrelser spørger efter, er dækning (andelen af aktiver, der rapporterer patchstatus), gennemsnitlig tid til afhjælpning pr. alvorsgrad og overholdelse af frister, med undtagelser registreret eksplicit. Kontrolankrene er CIS Controls v8 Control 7 (Safeguard 7.3 og 7.4 om automatiseret patching af styresystemer og applikationer), ISO/IEC 27002:2022 kontrol 8.8 (håndtering af tekniske sårbarheder) og NIS2 art. 21, stk. 2, litra e, om håndtering af sårbarheder. Patch management supplerer sårbarhedsscanning, der verificerer, at patches faktisk er installeret, og hærdning, der fjerner komponenter, som ellers skulle patches."},"edges":[{"type":"requires","to":"cs/patch","confidence":"high","strength":"normal"},{"type":"requires","to":"security/cve","confidence":"high","strength":"normal"},{"type":"kind-of","to":"security/control","confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/vulnerability","why":{"en":"Installing the fix removes the known weakness itself.","da":"Når rettelsen installeres, fjernes selve den kendte svaghed."},"confidence":"high","strength":"primary"},{"type":"mitigates","to":"security/ransomware","confidence":"medium","strength":"normal"},{"type":"mitigates","to":"security/exploit","confidence":"high","strength":"normal"},{"type":"used-with","to":"security/vulnerability-scanning","confidence":"high","strength":"normal"}],"depth":3,"sources":[{"title":"Cyber Security Fast Track - Ordliste","tier":"course-material"},{"title":"NIST SP 800-40 Rev. 4 - Guide to Enterprise Patch Management Planning","tier":"standard","publisher":"NIST"},{"title":"CIS Critical Security Controls v8 - Control 7","tier":"standard","publisher":"Center for Internet Security"}],"draft":true}