{"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://atlas.maintz.dev/)"},"id":"security/patch-management","url":{"en":"https://atlas.maintz.dev/en/terms/security/patch-management/","da":"https://atlas.maintz.dev/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 US federal agencies must act on under Binding Operational Directive 26-04 (June 2026, replacing BOD 22-01), with a deadline for each CVE set by the asset's exposure, KEV status, whether exploitation can be automated and the technical impact, as short as three days for an internet-facing asset with an automatable KEV that gives total control; 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 amerikanske føderale myndigheder skal handle på efter Binding Operational Directive 26-04 (juni 2026, der afløste BOD 22-01), med en frist for hver CVE, der afhænger af aktivets eksponering, KEV-status, om udnyttelsen kan automatiseres, og den tekniske konsekvens, helt ned til tre dage for et internetvendt aktiv med en automatiserbar KEV, der giver fuld kontrol; 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."},"howTo":{"steps":{"en":["Name an owner for patching each asset type, including outsourced systems, and write the responsibility into contracts with IT suppliers.","Keep a complete inventory of hardware, operating systems, applications and firmware, so you know what needs patching.","Set deadlines by risk in a patch policy, for example emergency patching within days for exploited flaws on internet-facing systems and a monthly cycle for the rest.","Check vendor advisories and the CISA KEV catalogue every day, and match new vulnerabilities against the inventory.","Prioritise by known exploitation, internet exposure and asset criticality, not by CVSS score alone.","Test patches on a pilot group, roll them out in rings to everyone else, and turn on automatic updates wherever it is safe.","When a patch cannot be applied, mitigate by changing configuration, isolating the system or virtual patching, and record a risk acceptance with an owner and an expiry date.","Verify installation with vulnerability scans, and replace or isolate end-of-life software that no longer receives updates.","Report coverage, time to patch and overdue exceptions to management every month."],"da":["Udpeg en ansvarlig for patching af hver type aktiv, også outsourcede systemer, og skriv ansvaret ind i kontrakterne med it-leverandørerne.","Hold en fuldstændig oversigt over hardware, styresystemer, applikationer og firmware, så I ved, hvad der skal patches.","Fastsæt frister efter risiko i en patchpolitik, fx nødpatching inden for få dage af udnyttede sårbarheder på internetvendte systemer og en månedlig cyklus for resten.","Tjek leverandørernes sikkerhedsmeddelelser og CISA's KEV-katalog hver dag, og afstem nye sårbarheder mod oversigten.","Prioritér efter kendt udnyttelse, eksponering mod internettet og aktivets kritikalitet, ikke kun efter CVSS-score.","Test patches på en pilotgruppe, rul dem ud i ringe til alle andre, og slå automatiske opdateringer til, hvor det er forsvarligt.","Når en patch ikke kan installeres, så afbød med konfigurationsændringer, isolering af systemet eller virtuel patching, og registrér en risikoaccept med ejer og udløbsdato.","Bekræft installationen med sårbarhedsscanninger, og udskift eller isolér end-of-life-software, der ikke længere får opdateringer.","Rapportér dækning, tid til patching og forsinkede undtagelser til ledelsen hver måned."]},"pitfalls":{"en":["Patching only Windows on Patch Tuesday and forgetting firmware, network devices, browsers and third-party software.","Treating VPN gateways and firewalls like any other system, although attackers often exploit flaws in them within days.","Assuming a deployed patch is installed without checking it with a scan."],"da":["Kun at patche Windows på Patch Tuesday og glemme firmware, netværksudstyr, browsere og tredjepartssoftware.","At behandle VPN-gateways og firewalls som alle andre systemer, selv om angribere ofte udnytter sårbarheder i dem inden for få dage.","At gå ud fra, at en udrullet patch er installeret, uden at tjekke det med en scanning."]},"guides":[{"title":"NIST SP 800-40 Rev. 4 - Guide to Enterprise Patch Management Planning","url":"https://csrc.nist.gov/pubs/sp/800/40/r4/final","publisher":"NIST","tier":"standard"},{"title":"Known Exploited Vulnerabilities Catalog","url":"https://www.cisa.gov/known-exploited-vulnerabilities-catalog","publisher":"CISA","tier":"official-doc"},{"title":"Vulnerability management guidance","url":"https://www.ncsc.gov.uk/guidance/vulnerability-management","publisher":"NCSC UK","tier":"official-doc"},{"title":"Opdater programmer løbende","url":"https://www.sikkerdigital.dk/virksomhed/syv-raad-om-it-sikkerhed/2-opdater-programmer-loebende","publisher":"Styrelsen for Samfundssikkerhed","tier":"official-doc","lang":"da"},{"title":"Cyberforsvar der virker","url":"https://samsik.dk/publikation/cyberforsvar-der-virker/","publisher":"Center for Cybersikkerhed (Styrelsen for Samfundssikkerhed)","tier":"official-doc","lang":"da"}]},"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"},{"title":"BOD 26-04 - Prioritizing Security Updates Based on Risk","url":"https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk","tier":"official-doc","publisher":"CISA"}],"draft":true}