Cisco's October bundle: 16 of 35 CVEs score 9.0 or more, 7 in NX-OS, and 20 are umbrella IDs with no bug count

Sixteen of Cisco's 35 CVE IDs score 9.0 or more, and 20 of the 35 are umbrellas

Cisco's advance notification of 7 October 2026 (version 1.1, final) lists 14 security advisories published that day. Counting the CVE identifiers in its tables and on each advisory page gives 35 (derived). By the score printed for each ID, 16 are Critical (9.0 to 10.0), 12 are High and 7 are Medium (derived). The biggest block of critical IDs is NX-OS, the operating system of Cisco's data-centre switches: 7 of the 16. Five of those seven sit in features of Nexus 3000 and standalone Nexus 9000 switches (NX-API, MPLS OAM and NGOAM), and each of Cisco's pages says an 'unauthenticated, remote attacker' could run code as root or cause a denial of service. The header of every one of the 14 advisories says 'No workarounds available'.

That is the checkable fact. This is what it does not establish. It does not establish that anyone is attacking these devices. For 13 of the 14 advisories Cisco's PSIRT says it 'is not aware of any public announcements or malicious use'; the 14th, for Finesse, says a public announcement exists and that no malicious use is known. No ID is in CISA's Known Exploited Vulnerabilities catalogue at the time of reading. It does not establish exposure: two of the three NX-OS features, NX-API and MPLS OAM, are 'disabled by default', and neither Cisco nor, in the reporting searched, any scanning firm publishes a count of switches with any of the three enabled or reachable beyond a management network. And it does not establish that there are 35 flaws. Twenty of the 35 IDs are umbrella IDs from four 'security hardening releases', each standing for 'multiple' bugs grouped by weakness type. Cisco does not say how many bugs.

This briefing reads Cisco's own pages: the advance notification, all 14 advisories and their machine-readable CSAF files, Cisco's blog post and FAQ on its new disclosure model, the CVE.org and NVD records, and CISA's catalogue file. They were read between 11:46 and 12:14 BST on Tuesday 13 October 2026, six days (derived) after publication. SecurityWeek's report of 8 October, which says Cisco 'announced patches for 35 vulnerabilities', was used as a pointer only. Its totals match Cisco's tables; its word 'bugs' does not, as the next sections show. This is a defender-level briefing: no exploit detail, no requests or commands, no proof-of-concept links, and every researcher Cisco credits is named only by employer or role.

Counting it Cisco's way: 14 advisories, 35 IDs and three meanings of critical

Cisco's advance notification groups the 14 advisories in three tables: NX-OS (7 advisories), the Application Policy Infrastructure Controller, APIC (3), and License On-Prem, Meraki and Finesse (4). The table below counts the CVE IDs by product line and by the score band of each ID's own score. The scores were read from each advisory page and checked against the CSAF file, the CVE.org record and the NVD record.

CVE IDs by product line and score band, counted from Cisco's advance notification and the 14 advisories of 7 October 2026 (derived; read 13 October 2026). An umbrella ID is one of the hardening releases' bundled IDs.

Product line	CVE IDs (critical / high / medium)	Umbrella IDs
NX-OS (Nexus, MDS, UCS)	14 (7 / 4 / 3)	6
License On-Prem	8 (5 / 1 / 2)	4
Meraki	7 (1 / 6 / 0)	7
APIC	5 (3 / 0 / 2)	3
Finesse	1 (0 / 1 / 0)	0
All	35 (16 / 12 / 7)	20

Critical means three different things in this bundle, and only the first is on Cisco's advance notification.

1. The advisory rating. Each advisory carries the rating of its worst ID: 8 of the 14 are Critical, 1 is High and 5 are Medium (derived). Fewer than a dozen advisories are Critical.

2. The ID's own score. 16 IDs score 9.0 or more. The 8 Critical advisories hold 29 IDs, so 13 IDs inside Critical advisories score below 9.0: four in NX-OS, three in License On-Prem and six in Meraki. Cisco's advance notification shows only the advisory rating and score, so a reader who stops there sees 29 IDs under a Critical heading, not 16.

3. Your exposure, which no Cisco page can score because it depends on which features are on and who can reach them.

Two Cisco-origin numbers disagree. First, CVE-2026-76459, the NX-OS out-of-bounds-write umbrella, is 9.8 on the advisory page, in the CVE.org record (last updated 9 October) and in the NVD record, but 8.8 with privileges required 'low' in the advisory's CSAF file. That file still read version 1.0.0, stamped 7 October, when it was fetched again at 11:52 BST on 13 October. If the file is right the critical count is 15 and NX-OS has 6 critical IDs, not 7. SecurityWeek and The Hacker News's trending list follow the 9.8. Second, the advance notification gives the License On-Prem Vulnerabilities advisory as Critical 10.0, while the advisory says Base 9.1 and its highest ID is 9.1. That does not change a band; the first discrepancy changes the count by one.

NVD lists all 35 IDs as 'Awaiting Analysis' and shows only Cisco's own scores, so there is no NVD-assigned score to differ from Cisco's. CISA's enrichment entry (CISA-ADP) attached to the CVE.org records marks Exploitation 'none' on all 35 IDs and Automatable 'yes' on 22 (derived count), with timestamps of 7 and 8 October.

'Security hardening release': what Cisco says it is, and why it is not a quiet label

Four of the 14 advisories are titled 'Security Hardening Release: October 2026', for NX-OS, APIC, License On-Prem and Meraki. The word 'hardening' sounds like routine tidying. Cisco's pages define it. The bugs are 'multiple internally discovered vulnerabilities', found 'during internal security testing using existing testing processes as well as frontier AI models'. Cisco has 'grouped these issues by their underlying vulnerability class' and assigned 'a single' CVE ID to each class. In Cisco's FAQ these are 'umbrella' CVE IDs, and the score of each is 'the highest severity (worst-case scenario) of all individual bugs that are grouped under that CWE category'.

Three things follow, all derived from Cisco's tables. First, 9 of the 16 critical IDs live in hardening releases: two in NX-OS, three in APIC, three in License On-Prem and one in Meraki. Second, the only 10.0 in the whole bundle, CVE-2026-76482 in License On-Prem, is a hardening-release ID, described as 'improper verification of cryptographic signature'. Third, each score is a ceiling for a class of bugs, not a description of any one bug. Cisco does not say how many bugs stand behind an ID, which of them carries the top score, whether that bug needs authentication, or whether it is reachable by default. The other 11 umbrella IDs are all High, 7.4 to 8.8, so no umbrella ID in the bundle is below 7.4.

Cisco's blog post on the new model, written by a Cisco vice president of information security (security assurance and response), explains the choice. Hardening releases 'will not have individual CVEs assigned to each bug as they have pervasive fixes and should be qualified and deployed urgently', and 'Assessing security risk CVE-by-CVE and applying point mitigations is no longer fit for purpose.' The FAQ gives the instruction: 'Customers are advised to upgrade immediately.' For a defender the unit of work is therefore the release, not the bug. Cisco is the vendor, the scorer and the grouper here, so the severity and the grouping come from one party. Its stated reason is a patching workflow that scales. The effect, which is not a criticism, is that an outsider cannot count, rank or check the bugs behind 20 of the 35 IDs.

NX-OS: seven critical IDs, five behind a feature and two that apply regardless of configuration

NX-OS runs Cisco's Nexus 3000, 7000 and 9000 data-centre switches, the MDS 9000 storage switches and the UCS 6000-series fabric interconnects. The table sets out, for each critical NX-OS ID, the exposure condition Cisco states and the mitigation Cisco states. Every cell comes from the advisories: NX-API, MPLS OAM, NGOAM and the hardening release.

The seven critical NX-OS IDs: what Cisco states about exposure and mitigation, from the four NX-OS advisories of 7 October 2026 (read 13 October 2026).

ID, feature and score	Exposure condition Cisco states	Mitigation Cisco states
CVE-2026-76471, NX-API, 9.8	Nexus 3000 and standalone 9000 with NX-API enabled; 'disabled by default'. Unauthenticated, remote. On UCS 6300 the interface is on by default but needs valid low-privileged credentials, so Cisco rates it High there.	A Live Protect shield. No workaround.
CVE-2026-76465, MPLS OAM, 9.8	Nexus 3000 and standalone 9000 with MPLS OAM enabled; 'disabled by default'; models with a Silicon One ASIC cannot enable it. Unauthenticated, remote.	Disabling the feature 'is a mitigation'; a Live Protect shield.
CVE-2026-76485, NGOAM, 9.8	NGOAM enabled is 'the only requirement'. Unauthenticated, remote. Default state not stated.	Disable NGOAM if not required; a Live Protect shield.
CVE-2026-76486, NGOAM, 9.8	NGOAM enabled plus either SRv6 or NV Overlay with a mapped VXLAN EVPN VNI and a learned peer.	Same as above.
CVE-2026-76501, NGOAM, 9.8	NGOAM and SRv6 both enabled; Nexus 3000 does not support SRv6.	Same as above.
CVE-2026-76455, hardening (improper access control), 9.8	'Regardless of device configuration' on MDS 9000, Nexus 3000, 7000 and 9000 (both modes) and UCS fabric interconnects. Bug count, authentication and default exposure of the worst bug: not stated.	None stated.
CVE-2026-76459, hardening (out-of-bounds write), 9.8 (CSAF file: 8.8)	Same as above.	None stated.

Reading the table. Five of the seven need an optional feature, and for two of the three features Cisco says the feature is off by default. That is a real limit on exposure, and it is a statement about a default, not about your estate: a switch that has carried NX-API or MPLS OAM for automation or diagnostics since installation is exposed to whichever IDs the feature gates, on a vulnerable release. For NGOAM, Cisco's advisory does not say whether the feature is on by default. The two hardening IDs have no feature gate at all, and they are the two Cisco says nothing further about.

Is it a management-plane problem? The NCSC's advice below is to keep management interfaces on a separate network. Cisco's wording for the OAM flaws is that crafted packets are 'sent to an IP interface' (NGOAM) or to 'an IP address on an affected device' (MPLS OAM): these are operations and diagnostics features that process traffic on routed interfaces. The mitigations Cisco states for them are to disable the feature, apply a Live Protect shield or upgrade. The pages do not offer an access-list control, so 'it is only reachable from our management network' has to be checked for each feature, not assumed.

Live Protect. Cisco calls its shields 'temporary mitigations to bridge the gap until software updates can be scheduled'. The pages list them for the five feature-gated critical IDs and for one Medium ID (the Python sandbox escape, where the shield protects only new CLI sessions). They are not listed for the two hardening IDs. The NX-OS configuration guide that Cisco points to was not read, so what a shield costs or covers is not established here.

The three Medium NX-OS advisories. The Python sandbox escape needs a local, low-privileged user who has Python execution privileges. The control-plane denial of service is unauthenticated and remote, and Cisco says the condition clears 'soon after the high rate of traffic is stopped'. The ACI contract bypass is unauthenticated and remote, and its fix needs three steps: upgrade the APIC, upgrade the ACI switches and apply a new configuration setting. For that advisory 'fixed' does not mean 'upgraded'.

License On-Prem, APIC, Meraki and Finesse: nine more critical IDs and one flaw with no fix yet

The other 9 critical IDs are 5 in License On-Prem, 3 in APIC and 1 in Meraki. Finesse has no critical ID, but it is the one flaw with no fixed release yet. The table keeps each product's stated facts beside what is not stated. The advisories are License On-Prem and its hardening release, the APIC hardening release with its command injection and file access advisories, the Meraki hardening release and Finesse.

License On-Prem, APIC, Meraki and Finesse as stated in Cisco's advisories of 7 October 2026, and what the pages leave out (read 13 October 2026).

Product	Stated	Not stated
License On-Prem (formerly Smart Software Manager On-Prem): 8 IDs, 5 critical	Two individually numbered flaws need no authentication: CVE-2026-20328 (arbitrary account password reset, 9.1) and CVE-2026-76454 (unauthenticated API: write files or cause a denial of service, 9.1). The other two in that advisory need administrator credentials (4.9), and Cisco says the four 'are not dependent on one another'. The hardening release adds three critical umbrellas (missing authentication 9.8, signature verification 10.0, protected credentials 9.1) and one High. Affects the product 'regardless of the software configuration'. First fix: 10-202609.	Bug counts behind the three critical umbrellas; whether any deployment is reachable from the internet; any workaround.
APIC: 5 IDs, 3 critical	Hardening release: three umbrellas, each 9.8, 'regardless of device configuration'. Two Medium flaws (6.5) need administrator credentials; one, the file-access flaw, could expose 'key materials that could be used to elevate privileges to root on the affected APIC and on managed switches'.	Bug counts behind the umbrellas; whether the controller is reachable beyond a management network; any link between the file-access flaw and the critical umbrellas.
Meraki: 7 IDs, 1 critical	One critical umbrella, CVE-2026-76464 (buffer management, 9.6), with an adjacent-network attack vector, and six High umbrellas. Applies 'regardless of device configuration' to campus gateways, MG, MR, MS, MV and MX. Four fixed-release rows are dated in the future ('mid-Oct 2026', 'late Oct 2026', 'mid-Nov 2026').	Which of your Meraki devices fall in the adjacent-network case; whether the future-dated releases have shipped.
Finesse: 1 ID, High 7.2	CVE-2026-20362, server-side request forgery, unauthenticated and remote, 'limited sensitive information'. Cisco 'is aware that a public announcement is available' and not aware of malicious use. 'Cisco plans to release software updates': first fixes dated January and February 2027. No workaround.	Any interim control; the content of the public announcement (not read and not linked here).

Cisco credits outside researchers for 10 of the 35 IDs: the four License On-Prem IDs in the main advisory, the two APIC Medium IDs, the three Medium NX-OS IDs and the Finesse ID. The other 25 were found internally, including every critical NX-OS ID. The two unauthenticated License On-Prem flaws were reported by a researcher at the NATO Cyber Security Centre, which Cisco abbreviates NCSC, and a researcher at CyStack. The NATO centre is not the UK's National Cyber Security Centre, whose guidance is cited below. The Finesse flaw was reported by researchers at Horizon3. Cisco says a public announcement exists but not where it is; it was not read and is not linked here.

Fixed releases: what Cisco's pages let you derive, and what they do not

Where a train has no fix, Cisco's row says 'Migrate to a fixed release'. The table gives, per product line, the first fixed release in each train for the critical IDs, as far as the page text allows. It was derived by comparing the advisories' own tables.

First fixed releases per train for the critical IDs, derived from the fixed-release tables in Cisco's advisories of 7 October 2026 (read 13 October 2026). A release or later fixes the issue.

Product line	First fixed release per train	Derivable from the page text?
License On-Prem	10-202609 (the hardening release's first fix; the other advisory needs 10-202608). 9-202601 and earlier: 'Migrate to a fixed release'.	Yes: 10-202609.
APIC	6.0(9h), 6.1(6g), 6.2(3g). 5.3 and earlier: 'Migrate to a fixed release'.	Yes.
Nexus 9000 in ACI mode	16.0(9h), 16.1(6g), 16.2(3g). The Medium contract-bypass flaw also needs APIC at 6.0(9h), 6.1(6g) or 6.2(3g) and a configuration setting.	Yes (the hardening release is the only critical ID there).
Nexus 3000 and standalone Nexus 9000	Hardening release: 10.3(10), 10.4(8), 10.5(6), 10.6(4). The NX-API, MPLS OAM and NGOAM advisories print no static table for these switches; they point to Cisco's Software Checker.	No. The lowest release fixing all five feature-gated critical IDs is not in the page text.
Nexus 7000 and MDS 9000	Hardening release only, as both are listed under 'Products Confirmed Not Vulnerable' for the three feature-gated flaws: Nexus 7000 8.4(14), with 8.3 and earlier to migrate; MDS 9000 9.4(5a), with 9.3 and earlier to migrate.	Yes, for the two critical IDs.
UCS 6300 to 6600 and X-Series Direct 9108	Hardening release: UCS Manager mode 4.3(6j) and 6.0(2e); Intersight managed mode 4.3(6.260049) or 4.3(6.260059) and 6.0(2.260080); 4.2 and earlier to migrate.	Yes, for the hardening IDs.
Meraki	By device family, for example MX 26.1.7 and 26.2.3, MR 30.7.3, 31.1.8.1 and 33.1.3, MG 26.1.4, MV 8.0. MS 18.1.9 is 'mid-Oct 2026'; MR and campus gateway 32.2.5 are 'late Oct 2026'; campus gateway 33.1.4 is 'mid-Nov 2026'.	Yes, per family, but four rows are not yet dated as shipped.
Finesse (High, not critical)	Finesse 15.0(1) SU3 (Feb 2027); Packaged and Unified CCE 15.0(1)ES202701 (Jan 2027); Unified CCX 15.0(1) SU2 (Feb 2027).	Yes, but none is released.

Two limits. First, the static text of the NX-API, MPLS OAM and NGOAM advisories contains Cisco's Software Checker, a form that returns a 'First Fixed' and a 'Combined First Fixed' release for the release you enter. It was not used for this briefing, because it is an interactive lookup and not a published table, so that step is for your own team. Those advisories link to the hardening release for 'further documentation of improvements and fixes', which suggests its fixed releases may also carry the feature-gated fixes. The page text does not say so, and that is inference. Second, several advisories say their release tables were accurate 'at the time of publication' and point to the bug IDs for 'the most complete and current information'. Re-read Cisco's pages on the day you change anything.

What the record does not establish

What Cisco's advisories, the CVE.org and NVD records and CISA's catalogue state, and what they do not, as read on 13 October 2026.

Topic	Stated on the record	Not stated
Exploitation	Cisco PSIRT 'is not aware of any public announcements or malicious use' in 13 advisories; Finesse: a public announcement exists, no malicious use. CISA-ADP marks Exploitation 'none' on all 35. None of the 35 is in CISA's catalogue (version 2026.10.08).	When Cisco last checked; any scan, honeypot or telemetry reading. No third-party report of attacks was found.
Exposure	NX-API and MPLS OAM 'disabled by default'; hardening releases apply 'regardless of device configuration'; UCS 6300's interface is on by default.	NGOAM's default; how many switches run NX-API, NGOAM or MPLS OAM; how many are reachable beyond a management network. No count from Cisco or a scan firm was found.
Chaining	The four License On-Prem IDs 'are not dependent on one another'. One APIC flaw could expose key material for root on the APIC and managed switches.	Whether any two flaws chain.
Bundles	20 IDs stand for 'multiple' bugs by weakness class; each score is the worst case.	The bug count, which bug carries the score, and its authentication and default exposure.
Workarounds	'No workarounds available' in all 14 headers; a disable-the-feature mitigation for four critical IDs; Live Protect shields for five critical IDs and one Medium.	A mitigation for 11 of the 16 critical IDs; what a Live Protect shield covers.
Fixes	Per-train fixed releases for the hardening releases, APIC, License On-Prem, Meraki and Finesse.	Per-train fixed releases for NX-API, MPLS OAM and NGOAM in the page text; whether the Meraki and Finesse releases have shipped.

CISA's catalogue. The catalogue file read at 11:50 BST on 13 October was version 2026.10.08, released 8 October at 20:09 UTC, with 1,739 entries (catalogue file, page). None of the 35 IDs is in it. The last Cisco addition was CVE-2026-76504 in Catalyst SD-WAN Manager on 30 September, which this site covered in an earlier briefing; before that came three in September (ISE on 16, Secure Email Gateway on 14 and Firewall Management Center on 9). The contrast is the point: an exploited Cisco flaw has a catalogue entry and a federal deadline, and nothing in this bundle has either. That can change in an hour.

Secondary reports. SecurityWeek and BleepingComputer, both of 8 October, repeat Cisco's counts and statuses and add nothing the primary pages do not say. SOCRadar's note says no exploitation had been confirmed as of 9 October; SOCRadar sells vulnerability intelligence and attack-surface tools, which gives it an interest in the topic. The Hacker News's 12 October recap lists 16 Cisco CVEs among its trending CVEs. They are exactly the 16 critical IDs counted here, and a trending list is a patch priority, not a report of attacks.

Five labels that sound like severity or safety

Each of these labels does the work of a control or a verdict. Each is accurate on Cisco's page and misleading if read alone.

Five labels in Cisco's October 2026 advisories, what each sounds like, and what the pages say.

Label	What it sounds like	What the pages say
'Security hardening release'	Routine tidying; bugs without a headline.	Four advisories, all rated Critical; 20 umbrella IDs; 9 of the 16 critical IDs; the only 10.0; 'upgrade immediately'.
'Critical'	This is dangerous to us.	A score for the flaw. Cisco itself lowers NX-API to High on UCS 6300 because credentials are needed; Critical advisories contain 13 IDs below 9.0; no page scores your exposure.
'Unauthenticated'	Anyone can do it.	Stated in the text for 7 critical IDs, but gated: NX-API and MPLS OAM are off by default, the OAM flaws need a reachable interface, and the 9 umbrella IDs give only a vector for their worst bug.
'No workarounds available'	Nothing can be done until you patch.	In the header of all 14 advisories, while four critical IDs have a disable-the-feature mitigation and five a Live Protect shield.
'Management plane'	Out of reach, behind the management network.	License On-Prem and APIC flaws are in a 'web-based management interface' or 'management API'. The NGOAM and MPLS OAM flaws are reached by packets sent to an IP interface or address, which a management-network rule may not cover.

UK: Cyber Essentials, the NCSC and NIS for network core and data-centre operators

The clocks that start on Cisco's 7 October 2026 publication, with the arithmetic (derived) and the wording each rests on.

Clock	Date	Basis
Cisco publication	Wednesday 7 October 2026, 16:00 GMT	'First Published' stamp on the advisories.
Days since publication, at read time	6 (derived)	7 to 13 October.
Cyber Essentials 14 days	Wednesday 21 October 2026 (derived); 22 October if counted from the NX-API table revised on 8 October	Updates fixing 'critical' or 'high risk' flaws, or CVSS v3 of 7 or above, within 14 days of release.
Days left at read time	8 (derived)	13 to 21 October.
Cisco's next scheduled publication	Wednesday 21 October 2026 (derived)	'First and third Wednesday of each month'; not a final commitment, with a seven-day advance notice when something is planned.
Meraki and Finesse fixes	Mid-October 2026 to February 2027	Cisco's fixed-release rows; the Cyber Essentials period runs from release.

Cyber Essentials v3.3. The requirements document (April 2026) says software in scope must be updated, including vulnerability fixes, 'within 14 days' of release where the vendor describes the flaws as 'critical' or 'high risk', or the CVSS v3 base score is 7 or above. It adds a caution: 'Some vendors release security updates for multiple issues with differing severity levels as a single update', and if such an update covers any critical or high-risk issue it must be installed within 14 days. That fits hardening releases exactly. By the derived counts, 28 of the 35 IDs score 7.0 or above, in 9 of the 14 advisories, and no umbrella ID scores below 7.4. The document's definitions put 'network software and firewall and router firmware' inside 'software', and 'networking equipment' inside 'devices', so firmware is in scope as read.

Three limits on that reading. First, scope is not automatic: the requirements apply to devices in the agreed scope that 'can accept incoming network connections from internet-connected devices', 'can establish outbound connections' via the internet, or 'control the flow of data' between those and the internet. The Security Update Management control lists servers, end-user devices, firewalls, routers and cloud services; switches are not named in that list. Whether a Nexus switch or a License On-Prem server is inside the boundary is a scope question for the Certification Body. Second, the 14 days run from release, so the Meraki and Finesse rows dated later have not started a clock. Third, the document defines vulnerability fixes to include 'configuration changes' approved by the vendor, while Cisco calls disabling a feature and a Live Protect shield 'temporary'. Whether an assessor accepts such a mitigation in place of the upgrade inside 14 days is not stated in the document, so ask before relying on it.

NCSC guidance. The NCSC's alert of 27 August 2026 is about operational technology (covered in an earlier briefing), but it says the broader pattern of disruptive activity against internet-exposed systems and edge devices affects 'all sectors'. Its boundary advice asks that devices that facilitate external connectivity be 'within vendor support, routinely updated by default', and that their management be 'only possible from a segregated management network that is not connected to the internet'. For organisations outside operational technology it lists 'applying vendor security updates promptly' and 'monitoring for unexpected configuration changes or outbound connections', and asks all organisations to register for the free Early Warning service. The older network devices guidance (published 25 September 2016) says 'Management of network elements should only be possible from the management network or from local management interfaces.' Neither names Cisco, and neither settles the OAM question above. The NCSC's vulnerability management guidance (reviewed 1 May 2026) treats updating as a business-as-usual control that vulnerability management validates, not an exceptional act.

NIS and the CAF. An operator of essential services under the NIS Regulations 2018 must 'take appropriate and proportionate technical and organisational measures' to manage risks to its network and information systems (regulation 10), must notify a significant incident (regulation 11) within 72 hours of becoming aware, and faces penalties of up to 17,000,000 pounds at the top tier (regulation 18). The NCSC's Cyber Assessment Framework outcome B4.d, vulnerability management, has no day count. Its 'achieved' column says announced vulnerabilities are 'tracked, prioritised and mitigated (e.g. by patching) promptly', and its 'partially achieved' column accepts that some vulnerabilities that are not externally exposed have temporary mitigations for an extended period. Data-centre operators are a separate case: Schedule 2 as read does not list data centres, and the Cyber Security and Resilience Bill would add them, with Ofcom as regulator, only 'through secondary legislation following Royal Assent' according to the government's factsheet. The Bill's Lords report stage was listed for 26 October 2026, a date the page says may be provisional, so the data-centre duty is not law at the time of reading.

What an assessor can ask. This is a reading of the wording above, not a statement by the NCSC or a certification body. Expect questions on the scope boundary and whether the switches are inside it; the list of Cisco devices and releases in scope; the date each fixed release became available and the date it was installed; evidence that NX-API, NGOAM and MPLS OAM are off or restricted; the vendor's support dates for each train; and, for anything not yet fixed, the interim control and who approved it.

What to do, in this order

The question this leaves

Cisco's pages can say what a flaw needs. They cannot say what your switches have. Which of your Nexus switches have NX-API, NGOAM or MPLS OAM switched on, which networks can send them traffic, and where is that written down?

Key facts