We have one decision today, not three threat stories.
The board has €800,000 left this year. We must choose one programme: OT network segmentation, data-exfiltration detection, or identity enrollment hardening against passkey vishing. The other two are explicitly pushed into next year, so the real question is not “which is important?” — all three are. The question is: which deferral creates the least unacceptable risk?
I want us to test this hard. Evidence strength first: are these threats immediate to our environment or just high-quality headlines? Then execution: what can €800,000 actually deliver in ninety days? And finally board language: what risk are we willing to sign our name under if we defer the other two?
Alex, Lena, James — I’ll want the threat, intelligence, and defensive feasibility separated cleanly. Elena, keep us honest on whether the FSB router angle changes the calculus or just the narrative. Pierre, I need the business loss model, not a wide range. Sofia, only jump in where deferral creates a real disclosure, resilience, or duty-of-care problem.
Let’s decide like this is going into tomorrow morning’s board pack.
Alex, assess the three candidate programmes for exploit immediacy and kill-chain closure in the next 90 days: (1) accelerating OT network segmentation against the FSB Center 16 router-targeting wave; (2) building data-exfiltration detection, using the Novo Nordisk case as a trigger but not accepting unverified attacker claims; (3) hardening identity enrollment against Pink/O-UNC-066-style Microsoft Entra passkey vishing. I need a ranked recommendation for where the remaining €800,000 reduces the most real attack path this year, and a clear statement of what risk we accept by deferring the other two.
My ranked recommendation: fund (3) Microsoft Entra passkey-enrollment hardening first. Okta reports that O-UNC-066/Pink has been targeting Entra passkey enrollment via vishing since April 2026; Marcus Vale’s identity read matches mine: this does not require breaking passkeys — it abuses the enrollment bootstrap. That is a clean attack path: call user → relay them into enrollment/auth flow → register attacker-controlled strong auth → durable account access. €800k here can actually close the chain inside 90 days: restrict FIDO2/passkey registration groups, require verified Temporary Access Pass or helpdesk proofing, lock down security-info registration with Conditional Access, and monitor new auth-method registration. That is money on the lock, not on a camera watching the thief leave.
Second: build data-exfiltration detection, but don’t let the Novo Nordisk claims drive fantasy scope. Novo officially confirmed unauthorized access to limited internal IT systems and external copying of certain non-public/personal data; CyberBrief says FulcrumSec’s larger 1.3TB/source-code/AI-model claims remain unverified. So this is real as a class — data theft — but the programme mostly improves detection and containment after initial access. Fund it after identity unless your current telemetry cannot answer “what left, from where, and by whom?”
Third: defer broad OT segmentation against the FSB Center 16 router wave, unless you have flat IT/OT connectivity or exposed/misconfigured routers touching OT paths. CISA and CyberBrief reporting say FSB Center 16 is targeting vulnerable/misconfigured routers, including weak SNMP configurations, with critical-infrastructure relevance. That is real. But segmentation is not the fastest fix for the router exploitation path; router hygiene, SNMP lockdown, exposed-device inventory, config review, and edge monitoring are the immediate blockers. Full OT segmentation is slow concrete work. Important, yes. Best €800k for 90-day kill-chain reduction? Not unless your OT network is already one bad router away from plant impact.
Risk accepted by deferring: OT segmentation deferral leaves pivot/blast-radius risk if routers are compromised; exfil detection deferral means slower discovery of stolen data and weaker regulatory/forensic posture; identity deferral leaves an active, human-operated enrollment-abuse path open. I would not accept that last one.
Alex, yes — hardening passkey enrollment materially breaks this kill chain, because Okta describes the campaign as abusing the Microsoft Entra passkey registration flow, not defeating passkeys cryptographically. BleepingComputer’s account says the operator relays credentials and MFA responses in real time; Okta says victims are steered to fake Entra-style passkey enrollment pages. So the trust failure is enrollment bootstrap: who is allowed to add a new FIDO2/passkey method, from where, and under what proofing condition.
My ranking: fund enrollment policy first, helpdesk workflow second, Conditional Access third. In Entra, restrict Passkey/FIDO2 registration to controlled groups, block broad self-service rollout until proofing is mature, and require a short-lived Temporary Access Pass or separately verified enrollment path for new phishing-resistant factors. Conditional Access still matters — especially controlling security-info registration — but if a phishable password plus relayed SMS/TOTP/push can authorize a new passkey, you have turned a strong factor into an attacker persistence mechanism.
Lena, apply evidence discipline. For each option, separate confirmed facts from unverified or narrative-heavy claims: FSB router campaign, Novo Nordisk exfiltration allegations, and Pink/O-UNC-066 passkey vishing. Which threat line has the strongest evidence of being active, relevant, and likely to touch a mid-to-large European enterprise in the next 90 days? Give a single funding recommendation and confidence level.
Halil, the clean split is this:
- FSB router campaign — Confirmed: joint U.S./U.K./allied guidance says FSB Center 16 continues exploiting poorly configured or vulnerable networking devices worldwide, with impacted foreign networks across sectors. Attribution confidence: high. Unverified/narrative-heavy: treating every router exposure as this specific FSB campaign, or merging it with Salt Typhoon just because some TTPs overlap.
- Novo Nordisk — Confirmed: Novo disclosed unauthorized access to limited internal systems and copying of non-public data. Unverified: FulcrumSec’s 1.3TB claim, $25M ransom, AI/model theft, two-month dwell time, leaked developer credential. This is an incident signal, not enough evidence for a broad campaign.
- Pink / O-UNC-066 passkey vishing — Confirmed: reporting tied to Okta says attackers are vishing Microsoft 365 users into enrolling attacker-controlled Entra passkeys, with real-time credential/MFA relay, across multiple industries. Attribution confidence: moderate for O-UNC-066/Pink, because the visible attribution chain is narrower than the FSB advisory set. Unverified: Europe-specific targeting.
My single funding recommendation: fund a 90-day identity defense sprint against passkey enrollment abuse and vishing-led account takeover — Entra authentication-method governance, alerting on new passkey/FIDO2 registrations, helpdesk callback controls, and user-facing passkey rollout comms. Confidence: moderate. Pink/O-UNC-066 has the strongest near-term enterprise-touch profile; FSB has stronger attribution, but Pink is more likely to hit a mid-to-large enterprise through normal Microsoft 365 identity operations.
James, evaluate execution feasibility. With €800,000 and a 90-day follow-up window, what can a security team actually deliver for: OT network segmentation; enterprise data-exfiltration detection; and identity enrollment/passkey hardening? Rank them by risk reduction per euro and speed to measurable control improvement. Your answer must be board-actionable: what we fund, what milestone the board should expect, and what we deliberately defer.
Halil, with €800k and 90 days, I would rank the spend this way:
Identity enrollment/passkey hardening — fund first: €250k–€300k. Fastest measurable risk reduction per euro. CISA treats phishing-resistant MFA as a priority control, and passkeys/FIDO-style authentication fits that lane. Board milestone: within 90 days, require phishing-resistant authentication for admins, executives, finance, remote access, and new device enrollment; clean up weak enrollment paths; and report coverage by privileged and high-risk users. Defer full workforce passkey migration if help desk capacity or device readiness will make it noisy.
Enterprise data-exfiltration detection — fund second: €300k–€350k. MITRE frames exfiltration as adversaries stealing data after collection and often packaging it to avoid detection, so the practical control is not “buy DLP everywhere”; it is high-signal monitoring on crown-jewel stores, unusual bulk downloads, abnormal outbound volume, cloud-storage uploads, and archive creation followed by egress. Board milestone: 90-day deployment of 8–12 production detections, tuned to named crown-jewel repositories, with incident playbooks and weekly false-positive reporting. Defer enterprise-wide DLP rollout and content inspection everywhere; that will burn the budget and drown the SOC.
OT network segmentation — fund third: €150k–€250k now, larger program later. CISA describes segmentation as splitting networks into protected subnetworks; that is absolutely useful, but in OT the 90-day deliverable is containment, not “segment the plant.” I checked with Sara on OT feasibility, and her advice matches my instinct: do passive asset/traffic mapping, design zones and conduits, lock down IT-to-OT paths, stand up or tighten an OT DMZ/jump-host path, and pilot enforcement on one non-critical cell. Board milestone: approved OT segmentation design, documented traffic baselines, deny-by-default for new IT-to-OT flows, and one validated pilot. Defer Level 0–2 microsegmentation, PLC/SIS path changes, and anything requiring production-line maintenance windows.
So my board ask is: approve €800k, but do not split it evenly. Spend roughly 35% identity, 40% exfil detection, 25% OT containment. In 90 days, the board should expect visible control coverage, not a transformation story: privileged passkey coverage, named exfil detections in production, and OT containment design plus one safe pilot. Anything deeper than that is a 6–18 month capital program.
James, fact base first: CISA describes segmentation as separating networks into protected subnetworks that restrict communications and help protect OT layers, and its ICS guidance explicitly says mitigations must account for layered OT systems and operational nuance. So my realistic 90-day OT milestone is not “segment the plant”; it is establish controlled Level 3 / 3.5 containment: passive asset and traffic mapping, approved zone/conduit design, an OT DMZ/jump-host path for remote/vendor access, deny-by-default rules for new IT-to-OT flows, and a small validated pilot on one non-critical cell or line. That gives the board a measurable control without touching controller-to-I/O or safety paths midstream.
I would defer deep Level 0–2 microsegmentation, PLC/VFD/SIS network changes, inline enforcement between controllers and remote I/O, and any rule change that could interrupt deterministic process traffic until a maintenance window and test validation. A bad firewall rule in enterprise IT causes tickets; a bad rule between a controller and a safety-relevant process can cause a false trip or, worse, mask a needed trip. Spend the 90 days reducing north-south blast radius and preparing safe cutovers, not proving cybersecurity urgency by gambling with uptime.
Pierre, model the board risk. Compare the likely business-loss scenarios if each programme is deferred to next year: OT disruption through router-to-network pivot, undetected data/IP exfiltration like the Novo Nordisk case suggests, and Microsoft 365 account takeover through passkey enrollment vishing. Avoid broad ranges; give a directional but concrete estimate of expected downside and tell us which €800,000 spend has the strongest economic case.
I would put the strongest economic case on the data/IP exfiltration programme. My board-planning estimate is €4.5m expected downside over 12 months, and I would present that explicitly as a modelled loss, not a reported Novo Nordisk loss. The hard anchors are that reporting says attackers claimed over 1TB / about 1.3TB of stolen data and a $25m ransom demand, while Novo confirmed unauthorized access to limited internal IT systems and exposure of pseudonymized clinical-trial data. On an €800k spend, that gives a modelled ~5.6x avoided-loss case if the programme materially improves detection of research, clinical, code, model, or partner-data exfiltration.
For OT disruption through router-to-network pivot, I would use €3.2m expected downside as a directional internal planning number only; I do not have current sourced data here for that exact router-to-OT incident path. This could outrank exfiltration if the business has one or two revenue-critical plants with weak segmentation, but without plant revenue-per-day and recovery-time assumptions, I would keep it second. For Microsoft 365 passkey-enrollment vishing, I would use €2.1m expected downside: the campaign evidence supports real account-takeover risk through fake Microsoft Entra passkey enrollment and downstream extortion, but the loss is usually more containable unless finance, legal, R&D, or executive accounts are compromised.
So my recommendation to the board is: spend the €800,000 first on exfiltration visibility, keep OT as the swing-risk that could move to first place if James confirms slow recovery or high plant concentration, and fund M365 passkey-vishing controls next for privileged and finance users.
What sharpened here is that the three options are not equal on evidence, immediacy, and deliverability. Alex, Lena, and James converged around identity enrollment hardening as the most actionable 90-day move: the attack path is clear enough, it closes at the enrollment bootstrap rather than “breaking” passkeys, and the controls are concrete — restrict who can register passkeys, tighten Temporary Access Pass and helpdesk proofing, put Conditional Access around security-info registration, and monitor new authentication-method enrollment.
The caveat is important: Lena rated the Pink/O-UNC-066 attribution as only moderate compared with the FSB advisory base, and Europe-specific targeting was not confirmed in what we heard. But the operational relevance is still strong because the technique maps directly onto Microsoft 365 and Entra risk, and James judged the spend-to-risk-reduction ratio as the best of the three.
On data exfiltration, the room has a split. Pierre makes the strongest board-loss case there, with a modelled €4.5 million downside and a roughly 5.6x avoided-loss argument if monitoring materially improves. But Lena and Alex both warned us not to overbuild the programme around the most dramatic Novo Nordisk claims. Novo confirmed unauthorized access and copying of certain non-public data; the larger 1.3TB, ransom, AI/model, dwell-time, and credential details remain unverified or externally claimed. So exfiltration detection is real and valuable, but the Novo case should be treated as a trigger for crown-jewel monitoring, not as fully validated proof of a comparable campaign.
For OT segmentation, we have the strongest state-actor evidence line in one sense: the FSB Center 16 router-targeting activity has high-confidence allied reporting behind it. What we do not yet have is closure on whether €800,000 in 90 days can safely produce enough OT segmentation value to beat the identity option, especially without plant-specific outage, recovery, and revenue assumptions.
That is why the next turn needs specialist pressure-testing rather than another general ranking. We need Elena to test whether the FSB evidence changes the capital decision, Sofia to frame the governance risk of deferring each option, Marcus to validate the passkey-enrollment controls, and Sara to tell us what OT segmentation can actually be done safely in 90 days.
Elena, pressure-test the FSB router option. Does a high-confidence FSB Center 16 router-targeting advisory change the board capital decision enough to beat identity enrollment hardening or exfiltration detection? Assume the CISO must fund only one €800,000 programme this year and defer the other two. Give a position, but do not convert every Russian-linked network operation into an OT catastrophe unless the pathway supports it.
No — a high-confidence FSB Center 16 router advisory changes the urgency of edge hygiene, but I would not let it beat identity enrollment hardening for the single €800,000 programme unless this company is in defense, telecoms, energy, government, healthcare, or has known unmanaged/exposed router management planes. The CISA advisory and CyberBrief reporting point to Russian state-sponsored abuse of poorly configured routers, weak/default credentials, legacy management protocols, and edge-device weaknesses. That is real, and strategically significant. But strategically significant is not the same as board-priority dominant.
The geopolitical signal is sharp: the same week, the UK/EU sanctioned Russian cyber networks, the EU denounced Russia’s malicious cyber ecosystem targeting member states and partners, and NATO condemned Russian malicious cyber activity. So yes, this is gray-zone pressure — coercion below open conflict, aimed at allied resilience and political nerves. But Alex is right if he says we need a pathway: router compromise gives access, persistence, and pivot potential; it does not automatically become an OT catastrophe unless those routers bridge operational environments, remote access, or segmentation controls.
My board call: fund identity enrollment hardening first. CyberBrief has current evidence of attackers abusing MFA registration/enrollment flows, including help-desk vishing and attacker-controlled authenticator registration, with a cited 178% year-over-year increase in fraudulent MFA device registration events. That control reduces exposure across Russian state activity, ransomware, insider-enabled abuse, and cloud compromise. I would make router remediation a mandatory fast-track hygiene workstream from existing infrastructure budget, not the one strategic €800k bet — unless exposure confirms the routers are the company’s crown-jewel access path.
Sofia, compare the governance and regulatory risk of explicitly deferring two of these three programmes to next year: OT segmentation, data-exfiltration detection, and identity enrollment/passkey hardening. Focus on duties the board can be challenged on after an incident — GDPR/NIS2/DORA-style resilience, sector duties, evidence of reasonable security — not generic compliance. Which single programme best reduces defensible-board-risk in 90 days?
Halil, my ranking is: 1) identity enrollment/passkey hardening, 2) data-exfiltration detection, 3) OT segmentation — unless this is a safety-critical or essential-service OT environment, in which case OT segmentation moves to first place.
For a board-defensibility lens, identity/passkey hardening is the best 90-day choice because it is concrete, measurable, and broadly preventive. Under NIS2 Article 20, management bodies of essential and important entities must approve and oversee cybersecurity risk-management measures and can be held liable for infringements of those measures; Article 21 requires appropriate and proportionate technical, operational, and organisational measures to manage network and information-system risk and minimise incident impact. Under GDPR Article 32, the controller/processor must maintain security appropriate to risk, including ongoing confidentiality, integrity, availability and resilience; the EDPB also links Article 32 to the ability to detect, address and report breaches. A 90-day identity programme gives the board evidence that it acted on a known dominant risk: account takeover and weak authentication.
Deferring data-exfiltration detection creates a different regulatory weakness: after a breach, the board may struggle to show when it became “aware” of personal-data loss for GDPR Article 33 purposes, where notification is required without undue delay and, where feasible, within 72 hours after awareness. But detection is more evidentiary than preventive. Deferring OT segmentation is defensible only if there is no immediate safety, continuity, or essential-service dependency; if the entity is NIS2-regulated critical infrastructure, or an EU financial entity with operational-resilience duties, postponing OT segmentation after known flat-network risk is the hardest decision to defend. I could not verify current DORA article-level detail here, so I would not cite DORA-specific obligations or clocks without checking the applicable competent-authority guidance.
Marcus, we need your specialist view on the Pink/O-UNC-066 passkey vishing scenario. If the board funds identity enrollment hardening with €800,000, what controls can be finished inside 90 days, what measurable risk reduction should the board expect, and what identity risk remains if the programme is deferred to next year? Also tell us whether €800,000 is overkill or genuinely needed.
Halil, I would fund it — but only if the €800k buys workflow change, not just “more MFA.” The documented attack is not breaking FIDO2/passkeys; Okta says O-UNC-066/Pink is steering users into a fake Microsoft Entra passkey enrollment flow, and the CyberBrief/BleepingComputer reporting says credentials and phishable MFA responses are relayed in real time. So the 90-day priority is to close the enrollment trust gap: restrict Entra passkey/FIDO2 registration to approved groups, protect “Register security info” with Conditional Access, require short-lived Temporary Access Pass for new passwordless method enrollment, and monitor every new passkey/security-info registration as a high-signal identity event.
Inside 90 days, a mature Microsoft 365 shop should be able to finish: policy scoping for passkey/FIDO2 registration, Conditional Access around security-info registration, helpdesk scripts that prohibit voice-call-driven enrollment, TAP issuance controls, executive/admin priority rollout, and detections for unexpected new passkey registrations. The measurable board outcome should be: near-100% coverage of privileged users, zero self-service passkey enrollment from unmanaged/untrusted contexts, all new passkey enrollments tied to approved TAP/helpdesk records, and a sharp reduction in successful attacker-controlled factor enrollment. I would not promise “90% less account takeover” without your baseline telemetry; I would promise materially lower persistence risk after a vishing event.
If deferred to next year, the residual identity risk is ugly: a user can be socially engineered through password plus SMS/TOTP/push, and the attacker may convert that momentary access into a durable attacker-controlled passkey. That is worse than ordinary credential theft because the attacker is adding a strong factor to their side of the trust chain. €800k is not overkill for a large enterprise with fragmented helpdesk, multiple tenants, VIP users, and weak telemetry; it is overkill for a single-tenant, already well-governed Entra environment where this is mostly policy work. My test: if the budget includes identity engineering, helpdesk redesign, logging/SIEM work, and privileged-user rollout, it is justified; if it is a vendor passkey project without enrollment governance, it is badly aimed.
Sara, assess the OT segmentation option against the FSB router-targeting wave. In a 90-day, €800,000 programme, what can actually be implemented safely without disrupting operations? Does router exploitation materially justify accelerating segmentation now, or is the faster risk reduction router hygiene, IT/OT access control, and monitoring? Give a clear fund/defer recommendation.
The FSB router wave justifies accelerating OT boundary containment, not a rushed plant-wide segmentation rebuild. The official advisory says Russian FSB Center 16 actors are scanning for poorly configured routers, abusing SNMP, Cisco Smart Install/CVE-2018-0171, and collecting configuration files from critical infrastructure networks. That points first at Purdue Level 4 to Level 3/3.5 choke points: routers, firewalls, OT DMZ paths, vendor access, and management planes.
My fund recommendation for the 90 days: fund router hygiene, IT/OT access control, and monitoring as the core programme, with segmentation limited to safe milestones. Implement: router/firewall inventory; disable Cisco Smart Install where present; move SNMP to v3 authPriv or remove it; restrict management access to jump hosts; block unnecessary SNMP/TFTP; rotate exposed community strings/credentials; back up and diff configs; tighten OT DMZ rules to named flows only; add passive monitoring/NetFlow at IT/OT conduits; and pilot segmentation on one non-critical cell after test validation.
Defer: deep Level 0–2 segmentation, PLC-to-I/O firewalling, safety controller communication changes, and broad inline enforcement inside production cells. CISA’s segmentation guidance says segmentation can protect OT layers and critical processes, but those changes can also interrupt the very process traffic we are trying to protect. A bad rule at the enterprise edge is recoverable; a bad rule between a controller and a safety-relevant device can trip the plant or blind an operator. So: fund accelerated boundary segmentation and router hardening now; defer intrusive plant-floor segmentation until maintenance windows and validated test plans.
The important shift is that the FSB router advisory became more specific, but not automatically more decisive for the capital choice. Elena and Sara both treated it as a real state-linked edge and infrastructure threat — especially around weak router management, SNMP, legacy Cisco Smart Install exposure, configuration theft, and possible pivoting — but neither turned that into a blanket argument for a full OT segmentation programme ahead of identity work. The practical interpretation is narrower: accelerate edge hygiene and OT boundary containment, particularly at IT/OT choke points, vendor access paths, management planes, and DMZ flows. That is different from promising a safe 90-day rebuild of plant segmentation.
On identity, Marcus reinforced the earlier conclusion with more operational detail. The passkey/vishing scenario is not “passkeys are broken”; it is an enrollment trust failure, where attackers manipulate users into registering or approving authentication methods through fake or relayed flows. That makes the 90-day control set quite concrete: restrict who can enroll FIDO2/passkeys, protect security-info registration with Conditional Access, use short-lived Temporary Access Pass under controlled workflows, harden helpdesk scripts, prioritize admins and executives, and treat new passkey or security-method registration as a high-signal event. The board benefit is measurable, but not absolute: it reduces the chance of attacker-controlled enrollment, while residual risks remain around helpdesk social engineering, unmanaged users, gaps in monitoring, and any population not brought under the policy quickly.
Sofia’s regulatory lens also matters because it frames the board’s defensibility after an incident. Her view was that identity hardening is the strongest general-purpose 90-day programme under GDPR Article 32 and NIS2 governance duties, because it is preventive, proportionate, and easy to evidence. She would move OT segmentation to first place only for safety-critical or essential-service OT environments. So the emerging consensus is conditional: for a typical enterprise, identity enrollment hardening still leads; for critical OT-heavy operators, boundary containment may need to be elevated, though not necessarily as a broad segmentation overhaul.
That leaves one unresolved pressure point: data and IP exfiltration detection. We have heard that identity controls are concrete and fast, and that router-driven OT work should be scoped carefully. The next challenge is whether an avoided-loss model for exfiltration detection — the claimed €4.5 million downside and 5.6x case — is strong enough to overturn that priority.
Claim: You recommend funding data/IP exfiltration detection because your model shows roughly €4.5m expected downside and ~5.6x avoided-loss case from an €800k spend.
Counter-evidence: Alex, Lena, James, Elena, Sofia, and Marcus are converging on identity enrollment hardening as the fastest broadly preventive control. Lena also warned that the larger Novo claims — 1.3TB, $25m ransom, AI/model theft, dwell time, leaked credential — are unverified; the confirmed Novo facts are limited internal-system access and copying of some non-public/personal data. Defend or revise the data-exfil recommendation under a strict board constraint: one €800,000 capital programme this year, two deferred to next year.
I would revise the funding call: under a one-programme-only constraint, the strongest €800,000 economic case is identity enrollment hardening, not the broader data/IP exfiltration programme. The reason is prevention leverage. The current evidence on the Microsoft 365 campaign is stronger: O-UNC-066/Pink is reported to use vishing plus fake Microsoft Entra passkey enrollment, adapt to MFA methods including TOTP, push, and SMS OTP, and pursue account takeover followed by data extortion across sectors. Locking down passkey/FIDO2 enrollment, using controlled proofing such as Temporary Access Pass, and monitoring new security-method registration cuts off both persistence and a major SharePoint/OneDrive exfiltration path.
If deferred to next year, I would price the expected downside this way: Microsoft 365 passkey-enrollment hardening deferred: €3.6m expected downside; data/IP exfiltration visibility deferred: €2.8m expected downside; OT router-to-network pivot deferred: €2.4m expected downside. The data/IP exfiltration case is lower than my earlier estimate because the Novo facts support unauthorized access and copied non-public/personal clinical-trial data, but the larger 1.3TB, $25m ransom, AI/model theft, and long dwell-time claims remain attacker claims or unverified reporting. OT stays material, but without current evidence tying this environment to revenue-critical plants and slow recovery, I would not put it above the identity control.
So, direct answer: approve the €800,000 identity enrollment hardening programme this year. Defer the data/IP exfiltration programme only with a board-visible exception: if crown-jewel R&D, trial, source-code, or model repositories sit outside Microsoft 365 behind weak developer tokens or service credentials, that exception could flip the ranking back.
Pierre, yes — for the Pink scenario, enrollment hardening is the faster preventive control. Okta says O-UNC-066/Pink targets Microsoft 365 passkey enrollment, and BleepingComputer reports that after account access Pink moves quickly into SharePoint and OneDrive exfiltration. So if you lock down who can register Entra passkeys/FIDO2 methods, require controlled proofing such as Temporary Access Pass, and monitor new security-method registration, you cut off both M365 account takeover persistence and a major downstream document-exfil path before the attacker reaches the data layer.
But I would not sell it as a universal exfiltration programme. The Novo material in CyberBrief says confirmed unauthorized internal-system access and copied non-public/personal clinical-trial data, while the 1.3TB, $25m ransom, AI-model theft, Azure container registry credential, and GitHub PAT details remain attacker claims or unconfirmed reporting. Enrollment hardening helps if the route is workforce Microsoft 365 identity; it does little against leaked developer tokens, service-account passwords, or repository secrets. Under a one-programme constraint, pick enrollment hardening if the board’s top 90-day risk is Pink-style M365 ATO; pick exfil visibility if the crown jewels sit outside M365 behind weak workload credentials.
What just changed is the economic ranking. Pierre has withdrawn the earlier stronger case for putting the €800,000 into a broad data/IP exfiltration detection programme, and he now puts identity enrollment hardening first under the “one programme only” constraint. That matters because the challenge was not whether exfiltration visibility is valuable; it was whether it is the best single use of the remaining capital when the Microsoft 365 passkey-enrollment campaign appears to offer more immediate prevention leverage.
His reasoning is that the current identity evidence is more concrete and more actionable: vishing, fake Microsoft Entra passkey enrollment, adaptation across MFA methods, account takeover, and then data extortion or cloud data theft through SharePoint and OneDrive paths. In his updated model, deferring Microsoft 365 passkey-enrollment hardening carries about €3.6 million in expected downside, versus €2.8 million for deferring data/IP exfiltration visibility and €2.4 million for deferring the OT router-to-network pivot work. So the room is no longer hearing a unified financial argument for exfiltration detection as the lead programme; the industry-impact view has moved into line with the identity-first camp.
The caveat is important: Pierre is not saying the Novo-style data/IP risk disappears, or that exfiltration monitoring is unnecessary. He is saying the supportable facts around unauthorized access and copied clinical-trial or personal data do not, on this record, beat the prevention value of closing the identity enrollment gap first. That keeps uncertainty in the discussion: the numbers are comparative estimates, not verified loss forecasts, and they depend on how much of the attack chain each programme can actually interrupt.
That brings us naturally to the next tension. If identity enrollment hardening is now the preferred programme, James previously suggested it might cost only €250,000 to €300,000. But the board question forces one programme to receive the full €800,000 while the others are deferred. So we need to test whether “identity first” really means spending the whole allocation there, expanding its scope, or whether the premise itself creates an inefficient funding decision.
James, you originally said identity hardening can be done for €250k–€300k, while the board question forces one programme to receive the full remaining €800k and the two losing programmes to be deferred to next year. Under that constraint, does identity still deserve the full allocation? If yes, define a scope that absorbs €800k without waste. If no, say whether data-exfiltration detection should win instead.
Halil, under the forced all-or-nothing constraint, identity does not get the full €800k. I still want the first €250k–€300k spent on phishing-resistant MFA/passkey enrollment, because CISA says FIDO/WebAuthn is the widely available phishing-resistant option and recommends starting with hosted mail, SSO, admins, and high-value users. But after that, the 90-day marginal return drops unless this is a very large workforce buying hardware keys at scale. Worse, CyberBrief has current reporting on fake Entra passkey enrollment/vishing, so throwing money at passkeys without tight enrollment governance can create a new help-desk and social-engineering attack surface.
So data-exfiltration detection should win the full €800k. It can absorb the money without waste: onboard crown-jewel SaaS, file-share, endpoint, proxy, and cloud-storage logs; deploy DLP/CASB controls where data actually leaves; tune detections for MITRE exfiltration patterns like cloud-storage upload and bulk file access; and buy 90 days of engineering/MDR surge capacity to make alerts actionable. Board milestone: by day 30, top 20 crown-jewel repositories and egress paths mapped; by day 60, 8–12 production detections live with playbooks; by day 90, measurable coverage for bulk download, unusual archive creation, external sharing, cloud-storage upload, and privileged data access. I would tolerate roughly 5–10% false positives during tuning, then force it under 2–3% for SOC-facing alerts before calling it operational.
What we deliberately defer: broad passkey rollout beyond admins/high-risk users, unless already licensed and ready; and OT segmentation beyond design work and emergency access tightening. That is not because identity or OT are unimportant — it is because €800k in 90 days buys a real exfiltration control layer, while full-program identity spend risks becoming device procurement and change-management theatre.
James has sharpened the budget problem in a different direction: identity hardening remains urgent, but he no longer sees it as the best destination for the entire €800,000 if the board really will fund only one programme and defer the other two. His distinction is important. He is not saying passkey enrollment governance is optional; he still wants the first €250,000–€300,000 spent there, especially for hosted mail, SSO, administrators, and high-value users. But under the artificial all-or-nothing rule, he thinks the marginal return after that point drops unless the organisation has a very large workforce and a hardware-key deployment that can use the extra capital efficiently.
The new argument is that data-exfiltration detection can absorb the full amount more productively. James framed it as a broader engineering and operational programme: mapping crown-jewel repositories and egress paths, onboarding SaaS, file-share, endpoint, proxy, and cloud-storage logs, applying DLP or CASB controls at real exit points, tuning detections for exfiltration patterns such as bulk access and cloud uploads, and buying a short-term engineering or MDR surge so the alerts are not just noise. That gives the board a more concrete way to spend the full budget without leaving a large unused remainder inside a narrower identity project.
There is also a caveat embedded in his answer: spending heavily on passkeys without tight enrollment governance could itself expand the help-desk and social-engineering attack surface, especially in light of current reporting about fake Microsoft Entra passkey enrollment and vishing. So the room is converging on a nuanced position, not a simple “identity versus data” split: identity may be the highest-priority first tranche, while exfiltration detection may be the better full-programme fit under the board’s rigid capital allocation rule.
The next challenge should test that nuance against the identity side. If identity enrollment hardening is still being recommended by some as the winner, the question now is whether it can justify the full €800,000 on its own—rather than merely justifying an urgent first phase.
Claim: You recommended funding identity enrollment hardening, but the board constraint is strict: the full €800,000 must go to one programme, and data-exfiltration detection and OT segmentation would be deferred to next year.
Counter-evidence: James now argues identity delivers the first €250k–€300k of high-value reduction, but the marginal return drops sharply after that unless hardware keys are bought at scale; he says the full €800k is better absorbed by data-exfiltration detection with crown-jewel log onboarding, DLP/CASB tuning, and MDR surge. Defend or revise: can identity enrollment hardening responsibly absorb €800k in... [arg clipped]
Halil, I’ll narrow my position: identity enrollment hardening is absolutely the first control to fund for Pink/O-UNC-066, but I would not defend spending the full €800k on enrollment-only work unless it includes hardware-key/passkey rollout at scale, helpdesk process redesign, Conditional Access, TAP governance, and monitoring. The evidence says the attacker path is fake Microsoft Entra passkey enrollment, real-time credential/MFA relay, and attacker-controlled passkey registration for persistent Microsoft 365 access — so the identity tranche is high-value. But Microsoft’s own controls here are fairly bounded: restrict passkey/FIDO2 registration, protect security-info registration with Conditional Access, and use Temporary Access Pass for controlled passwordless enrollment.
So I agree with James on marginal return. If the board forces one programme to absorb the whole €800k, data-exfiltration detection is the more responsible full-budget sink: Microsoft Defender for Cloud Apps and Purview cover Microsoft 365 audit logs, SharePoint/OneDrive file scanning, sensitivity labels, DLP, OAuth app visibility, compromised-account detection, and forensic audit trails. That maps directly to the downstream extortion risk after M365 account takeover.
My revised recommendation is: spend €250k–€300k immediately on identity enrollment hardening if splitting is allowed. Under the strict “one programme only, full €800k” constraint, choose data-exfiltration detection — unless identity is explicitly expanded beyond enrollment into enterprise-wide phishing-resistant rollout and device-bound access for high-risk users.
Yes, Marcus — that is fair. The current O-UNC-066/Pink reporting makes identity enrollment control a must-fund first tranche, because the abuse path is fake Entra passkey enrollment via vishing, real-time credential/MFA relay, and attacker-controlled passkey registration for persistent M365 access. Microsoft has the right controls to harden that path — TAP, Conditional Access around security-info registration, passkey/FIDO2 policy, and audit visibility — so €250k–€300k can be spent cleanly on admin/high-risk rollout, enrollment governance, help-desk workflow lockdown, and monitoring.
But if the board forces one programme to take the full €800k, I would put it into data-exfiltration detection unless identity includes hardware keys at scale, privileged-user/device rollout, and serious change-management capacity. The downstream risk in the reporting is M365 access leading to data theft/extortion, and the Microsoft stack has usable SharePoint/OneDrive, Defender for Cloud Apps/Purview, DLP, audit, and OAuth-app control points. My practical call: fund identity enrollment hardening as a critical control when budgets can be split; under one-programme-only rules, exfil detection absorbs €800k with less waste and gives the board broader measurable coverage.
Marcus has now put a clear boundary around the identity argument: identity enrollment hardening is still the first control he would fund against the Pink/O-UNC-066 path, but he would not treat “enrollment hardening only” as a natural €800,000 programme. That matters because it separates priority from budget absorption. The attack path he is worried about remains very concrete — fake Microsoft Entra passkey enrollment, real-time credential and MFA relay, and attacker-controlled passkey registration leading to persistent Microsoft 365 access. But the core Microsoft controls he names are also relatively bounded: restrict passkey/FIDO2 registration, protect security-info registration with Conditional Access, and govern Temporary Access Pass use.
So the room now has convergence between James and Marcus: spend the first tranche on identity, yes; force the entire annual capital allocation into identity enrollment alone, probably not, unless the scope expands into a broader rollout with hardware keys or passkeys at scale, helpdesk redesign, Conditional Access, TAP governance, and monitoring. That is a caveat, not a dismissal. It means the identity programme is high-value but may become inefficient or artificially inflated under the board’s all-or-nothing rule.
Marcus therefore moves toward data-exfiltration detection as the more responsible full-budget destination. His reasoning is that Microsoft Defender for Cloud Apps and Purview can cover a wider set of controls: Microsoft 365 audit logs, SharePoint and OneDrive file scanning, sensitivity labels, DLP, OAuth app visibility, compromised-account detection, and forensic audit trails. We should be careful not to overstate this as fully validated implementation certainty; we have not yet tested the 90-day delivery assumptions, telemetry quality, licensing dependencies, or operational capacity. But the strategic direction is sharper now: if the board insists on one €800,000 programme, the debate is increasingly about whether exfiltration detection gives broader coverage while preserving enough identity work as a critical first tranche.
That is why the next turn goes wider. We need the threat-hunting, intelligence, regulatory, and cloud/SaaS perspectives to pressure-test whether this emerging preference for data-exfiltration detection holds up across attacker behaviour, compliance exposure, and practical Microsoft 365 delivery.
Alex, we have a constraint shift: James, Pierre, and Marcus now say identity enrollment hardening is high-value but hard to justify as the full €800k programme; they prefer data-exfiltration detection if the whole allocation must be used by one programme. Re-rank under that strict rule. Which single programme gives the best 90-day reduction in real attack outcomes, not just first-euro efficiency? State what evidence would make your answer wrong.
Under the strict “spend the whole €800k on one programme” rule, I’d re-rank to 1) data-exfiltration detection, 2) identity enrollment hardening, 3) OT segmentation. I still think Entra passkey enrollment hardening is the cleanest first-euro kill-chain break, but James, Pierre, and Marcus are right on the full-programme constraint: exfiltration detection uses the whole budget better and cuts across more real outcomes in 90 days.
The evidence points that way. Novo Nordisk confirmed unauthorized access and external copying of non-public/personal data; multiple reports say FulcrumSec’s wider 1.3TB/$25M/IP claims are still not independently verified. Separately, the O-UNC-066/Pink Entra passkey campaign is aimed at account takeover followed by data extortion. And the FSB Center 16 router activity is described as espionage-oriented router access through weak SNMP/default/legacy management paths. Different doors, same prize: data leaving the building. Spend the €800k on SaaS/cloud/endpoint egress telemetry, high-value repository monitoring, anomalous download detection, token misuse visibility, and rapid containment hooks. Not just dashboards. Dashboards are a rear-view mirror.
Risk accepted by deferring identity: the Entra passkey vishing path remains a live account-takeover route, especially during passkey rollout. Risk accepted by deferring OT segmentation: a compromised router can still become a stealth foothold or pivot point, though router hygiene is the faster blocker than full segmentation. What would make this answer wrong: proof that your Entra tenant is actively being targeted or already has suspicious new passkey/FIDO2 registrations; evidence of flat IT/OT routing from exposed network devices into plant systems; or if the exfil programme is only passive alerting with no containment authority. In those cases, I’d move identity or OT back above exfil.
Lena, update your recommendation after hearing the budget-absorption problem: identity may be the strongest immediate attack path, but a full €800k identity-enrollment-only programme may have diminishing returns; data-exfiltration detection can absorb more capital and protects downstream extortion risk. Which programme should the board fund under the forced single-programme rule, and how should we word the evidence caveat around Novo?
Fund the data-exfiltration detection and extortion-resilience programme, not an €800k identity-enrollment-only programme. My confidence is moderate: Pink/O-UNC-066 is the sharper 90-day entry-path signal for Microsoft 365 account takeover, but the endgame repeatedly described is data extortion, and Novo’s confirmed boundary is also data copying — so exfil detection absorbs the budget better while still covering the downstream risk from identity compromise.
Board caveat wording: “Novo Nordisk has confirmed unauthorized access to internal IT systems and external copying of non-public data; broader FulcrumSec claims about 1.3TB stolen, source code, AI models, ransom amount, initial access via GitHub token, and dwell time remain unverified and should not be treated as established facts.”
ATT&CK framing: Pink/O-UNC-066 maps cleanly to social engineering / credential capture leading to account takeover and authentication-method abuse; the funded control should watch for new passkey/FIDO2 enrollment followed by abnormal bulk access, staging, or outbound transfer.
Sofia, revisit your ranking under the strict all-or-nothing capital rule. If identity enrollment hardening cannot responsibly absorb the whole €800k without becoming broad passkey rollout, does data-exfiltration detection become more defensible for board duty-of-care, GDPR Article 32, NIS2 risk management, and post-incident scrutiny? Give the exact board-safe rationale and the residual regulatory risk of deferring identity and OT to next year.
Yes — under the strict all-or-nothing €800k rule, I would move data-exfiltration detection to first place for board-defensible regulatory risk reduction in 90 days. The board-safe rationale is: identity hardening is important, but if it cannot responsibly absorb the full capital allocation without becoming an over-broad rollout, the more defensible use of the whole budget is a detection-and-evidence capability that directly supports GDPR Article 32 “security appropriate to risk,” GDPR Article 33 breach-awareness and 72-hour notification readiness, and NIS2 Article 20/21 management oversight of cybersecurity risk-management measures.
The board minute should be explicit: “The board approved the programme that most improves breach discovery, containment evidence, affected-data scoping, and regulator-facing incident documentation within 90 days.” That matters because GDPR Article 33 notification runs from awareness, and Article 33(5) requires breach documentation; weak exfiltration visibility is exactly what later makes a controller look unable to determine what happened, when it became aware, and which data subjects were affected. For NIS2 entities, this also aligns with the management-body duty in Article 20 to approve and oversee cybersecurity risk-management measures and the Article 21 requirement for proportionate technical and organisational measures. I would not overstate DORA article-level obligations here because I have not verified current DORA text in this turn; for an EU financial entity, map the same decision to ICT-risk detection and incident evidence requirements before final approval.
Residual risk is real. Deferring identity leaves a foreseeable access-control weakness: if the incident starts through account takeover, weak enrollment, or phishing-resistant authentication gaps, the board will need evidence that it considered that risk and adopted interim controls, not merely postponed it. Deferring OT segmentation is defensible only if OT is not safety-critical, not essential-service-impacting, and not currently flat or externally reachable; otherwise it is the hardest deferral to defend under NIS2-style resilience scrutiny. The board should pair the exfiltration programme with a dated risk acceptance for identity and OT, named executive owners, interim compensating measures, and a Q1 funding trigger.
Priya, on-demand cloud/SaaS lens: if the board chooses the €800k data-exfiltration detection programme, what cloud/SaaS controls can be delivered in 90 days across Microsoft 365, cloud storage, endpoints, proxy/SSE, and SIEM/MDR? Define scope tightly enough that the board can measure delivery, and identify the top failure modes that would make this spend ineffective.
Halil, I’d keep the €800k programme deliberately narrow: detect and contain SaaS data movement, not “solve DLP.” In 90 days, the measurable scope should be Microsoft 365 first: SharePoint, OneDrive, Teams file stores, Exchange, Entra ID sign-ins, OAuth app activity, plus sanctioned cloud storage seen through proxy/SSE or Defender for Cloud Apps. Microsoft documents audit events for SharePoint/OneDrive downloads, sync downloads via OneDrive.exe, search queries, and sharing changes; Defender for Cloud Apps has policy templates for mass download, impossible travel, files shared to personal/unauthorized domains, and new cloud storage apps. That is enough signal to build a board-measurable control plane.
The 90-day delivery target should be: 1) Microsoft 365 audit coverage confirmed, with retention/licensing documented; Microsoft says Entra ID, Exchange, SharePoint, and OneDrive audit records are retained for one year by default for E5/Purview Audit-qualified users. 2) Ten production detection use cases in SIEM/MDR: mass SharePoint/OneDrive download, OneDrive sync bulk download, unusual SharePoint search, external/personal-domain sharing, unauthorized-domain sharing, impossible travel, suspicious OAuth app file downloads, new cloud storage app discovery, risky admin/RBAC activity, and endpoint RMM correlation. 3) A containment runbook that revokes sessions/OAuth grants/app consent and disables sharing links before anyone celebrates rotating passwords. Cloud marketing calls it “collaboration”; the attacker calls it an API.
For endpoints and proxy/SSE, don’t boil the ocean. Tie endpoint telemetry to the SaaS user/device: OneDrive.exe sync download events, browser downloads from SharePoint/OneDrive, and unauthorized remote-management tooling should be correlated with M365 alerts. That last point matters because our CyberBrief evidence had an Azure breach where the actor used social engineering/SSPR abuse, Microsoft Graph enumeration, RBAC escalation, movement into App Services, Key Vault, Storage, and SQL, then deployed ScreenConnect RMM and exfiltrated data — a reminder that “no malware” does not mean “no endpoint relevance.”
Top failure modes: buying tooling without M365 audit/licensing coverage; relying only on endpoint DLP while OAuth apps or Graph API do the downloading; leaving proxy/SSE blind to unmanaged devices and direct SaaS access; using default mass-download thresholds like “50 downloads in one minute” without tuning for executives, finance, legal, and sync clients; and sending alerts to SIEM/MDR with no revocation authority. Shared responsibility is very clear here: Microsoft provides audit and detection surfaces; the customer owns policy, consent governance, log routing, alert triage, and cutting off the delegated trust.
The ranking has shifted because the constraint changed: if the board must fund one full €800,000 programme, the room is now converging on data-exfiltration detection as the most defensible first choice. Alex, Lena, and Sofia all keep identity enrollment hardening as high-value, especially against the Pink/O-UNC-066 Microsoft 365 account-takeover path, but they no longer see an identity-enrollment-only programme as the best way to absorb the whole allocation without stretching into a broader passkey rollout.
What sharpened here is the distinction between the best first control and the best full programme. The identity path is still concrete: credential/MFA relay, malicious or attacker-controlled authentication-method enrollment, and persistence into Microsoft 365. But the common impact across the scenarios is data leaving the organisation. Alex framed it well: the Novo Nordisk-confirmed fact pattern is unauthorized access and external copying of non-public or personal data, while the larger FulcrumSec claims remain unverified. Lena preserved the same caveat for the board: do not treat the 1.3TB figure, source-code or AI-model claims, ransom amount, GitHub-token initial access, or dwell time as established facts unless independently verified.
Sofia adds the governance reason this matters. A detection-and-evidence programme is easier to defend under GDPR and NIS2 because it improves breach awareness, containment evidence, affected-data scoping, and incident documentation. That is not just a technical argument; it is a board-duty argument. If the organisation cannot tell what was accessed, copied, staged, or transferred, it is weaker both operationally and regulatorily.
Priya then made the programme concrete enough to avoid becoming a vague “DLP transformation.” The proposed 90-day scope is SaaS data movement, led by Microsoft 365: SharePoint, OneDrive, Teams file stores, Exchange, Entra sign-ins, OAuth app activity, sanctioned cloud storage, proxy/SSE signals, and SIEM/MDR detections for mass download, sync abuse, unusual search, risky sharing, and related behaviours. That gives James a clearer close for the board memo: not “identity is unimportant,” but “under the all-or-nothing capital rule, exfiltration detection is the programme that best uses the full €800,000 while still catching the downstream consequences of identity compromise.”
James, close this for the board memo. The room has moved from first-euro efficiency to the strict all-or-nothing rule: fund one €800,000 programme this year, defer the other two to next year. Current convergence is data-exfiltration detection/extortion resilience, with identity enrollment and OT segmentation deferred unless there is active Entra passkey abuse or unsafe IT/OT exposure. Give the 90-day execution plan, milestones, success metrics, and the exact residual-risk wording you would want the CISO to put in front of the board.
Halil, I’d close it like this: fund the full €800,000 data-exfiltration detection and extortion-resilience programme. The reason is execution capacity: MITRE documents cloud-storage data theft paths including SharePoint and OneDrive, Microsoft Purview/Defender tooling gives us audit, DLP, file monitoring and governance control points, and CISA’s ransomware guidance explicitly includes data extortion preparation and response. Identity gets only emergency containment if active fake-passkey abuse is found; OT gets only emergency isolation if there is unsafe IT/OT exposure.
90-day plan:
- Days 0–30: map top 20 crown-jewel repositories, M365/SharePoint/OneDrive/Teams/Exchange audit coverage, external sharing, privileged data access, and main egress paths. Milestone: board gets a named data-risk register, not a heat map.
- Days 31–60: deploy tuned detections for bulk download, abnormal SharePoint/OneDrive access, archive creation before egress, upload to unsanctioned cloud apps, suspicious OAuth access, and privileged access to sensitive libraries. Use existing SIEM/SOAR/DLP/CASB/MDR capacity before buying more tooling.
- Days 61–90: run two extortion-response exercises, tune alert volume, prove containment actions: disable account/session, revoke OAuth app, quarantine file, remove external collaborator, preserve evidence, and brief legal/comms.
Success metrics for the board: 90%+ audit coverage for named crown-jewel stores; 8–12 production detections live; SOC-facing false positives under 3% after tuning; critical exfil alerts triaged within 30 minutes; containment playbooks tested twice; and weekly reporting on external sharing, anomalous downloads, and blocked/quarantined events. Exact residual-risk wording I’d put in the memo: “This funding materially improves our ability to detect and contain data theft and extortion within the 90-day window. It does not complete phishing-resistant identity migration or OT segmentation. The board accepts residual risk of account-takeover via weak enrollment paths and lateral movement across insufficiently segmented OT/IT environments until next year’s funding cycle, unless active Entra passkey abuse or unsafe IT/OT exposure triggers emergency containment.”
James has now turned the room’s convergence into a board-ready recommendation: fund the full €800,000 data-exfiltration detection and extortion-resilience programme this year, while deferring the broader identity-enrollment and OT programmes unless emergency conditions are discovered. The important shift is not that identity or OT stopped mattering. It is that, under the strict all-or-nothing funding rule, James sees this programme as the one with the clearest execution path, the strongest mapping to current threat behavior, and the best fit for existing Microsoft 365, Purview, Defender, SIEM, SOAR, DLP, CASB, and MDR control points.
What the room has learned is that this is not simply a “buy more tools” recommendation. James is framing the first 90 days around naming and instrumenting the real data-risk surface: crown-jewel repositories, SharePoint, OneDrive, Teams, Exchange, external sharing, privileged access, and egress paths. That matters because it gives the board something more concrete than a generic risk heat map. The second month then turns that map into tuned detection for bulk download, abnormal cloud-storage access, archive creation before egress, unsanctioned cloud upload, suspicious OAuth access, and sensitive-library privilege use. By the third month, the programme moves into extortion-response exercising, so the organization is not only trying to see data theft earlier but also preparing for the pressure campaign that follows.
The caveat is also clear. This does not fully retire the identity-enrollment concern, especially if there is evidence of active fake-passkey or account-takeover abuse. Nor does it remove the OT concern if unsafe IT/OT exposure is found. James is recommending emergency containment for those cases, not pretending they are irrelevant. But for the board memo, the decision logic is now tight: choose the programme that can consume the full allocation responsibly, improve visibility over the assets attackers monetize fastest, and create measurable 90-day progress toward resisting data theft and extortion. From here, the final synthesis can separate the funded recommendation from the deferred-but-watched risks.
Board memo — decision: Allocate the remaining €800,000 to a 90-day data-exfiltration detection and extortion-resilience programme. Identity enrollment hardening and OT network segmentation are both important, but under the strict one-programme rule they are deferred to next year as capital programmes. The panel’s rationale is that exfiltration visibility best absorbs the full budget, improves breach discovery and containment, and also reduces the downstream impact of identity compromise and router-enabled intrusion paths.
Novo Nordisk has confirmed unauthorized access and copying of non-public data; broader attacker claims around volume, ransom, source code, or AI-model theft remain unverified and should not drive the board decision as fact.
Pink/O-UNC-066-style passkey vishing is a credible near-term account-takeover path, but the high-value identity enrollment controls are relatively bounded and may not responsibly consume the full €800,000 alone.
The FSB Center 16 router-targeting advisory is high-confidence and relevant, but it supports urgent edge hygiene and IT/OT boundary control more than a rushed full OT segmentation rebuild.
Data-exfiltration detection gives the board the strongest 90-day evidence position: detection, containment, affected-data scoping, legal notification readiness, and extortion response.
Fund the €800,000 data-exfiltration detection programme: map top 20 crown-jewel repositories, enable Microsoft 365/SaaS audit coverage, and deploy 8–12 tuned detections for bulk download, abnormal sharing, OAuth abuse, archive staging, and unsanctioned cloud upload.
Defer identity enrollment hardening to next year as a capital programme, while using existing controls to restrict high-risk passkey/FIDO2 registration and monitor new authentication-method enrollment.
Defer OT segmentation to next year as a capital programme, while maintaining no-new-capital emergency hygiene for exposed routers, SNMP, management planes, and IT/OT access paths.
Report back to the board in 90 days with audit coverage, detection performance, alert triage time, containment exercise results, and residual risk for the two deferred programmes.