Threat Intelligence

Miltech Cybersecurity: The Complete Buyer's Guide for Defence Contractors

Cyber miltech is not enterprise security with a camouflage skin — it is a distinct discipline shaped by nation-state adversaries, dual-use IP, export regulations, and mandatory NCCC compliance. This guide covers the threat landscape, NIST CSF mapping, the MDR/CTI/ZTNA stack, and a vendor-selection checklist for defence technology companies.

AmonSul Threat Intelligence TeamThreat Intelligence, AmonSul
(updated 26 April 2025)
15 min read

Defence technology companies — manufacturers of unmanned systems, C4ISR hardware, electronic warfare components, ballistic materials, and military-grade software — occupy a specific and exposed position in the threat landscape. They hold intellectual property that nation-state actors are specifically tasked to steal. They handle classified or export-controlled data that foreign intelligence services actively target. And they operate in a regulatory environment — Ukraine's NCCC framework, the EU's NIS2 Directive, NATO IAMD standards — that is evolving faster than most security programmes can track.

Miltech cybersecurity — shorthand for the security discipline covering defence technology companies and their supply chains — is not enterprise security with different stickers. It is a distinct practice shaped by adversary profile, asset sensitivity, and regulatory obligation. This guide explains what makes cyber miltech different, maps the relevant controls to the NIST Cybersecurity Framework, describes the minimum viable security stack, and provides a vendor-selection checklist that cuts through the marketing.

What is Miltech Cybersecurity?

Defining the Miltech Sector

"Miltech" covers companies that design, develop, manufacture, or integrate technology for military and defence applications. The category is broader than it might appear:

  • Prime contractors and system integrators working on platforms (UAV, armoured vehicle, naval)
  • Component manufacturers supplying optics, propulsion, communications, and electronics
  • Software companies building C2 platforms, ISR analysis tools, and battlefield management systems
  • Dual-use companies whose civilian and military product lines share development infrastructure
  • Supply chain participants providing materials, subassemblies, or services to any of the above

A company need not hold a government defence contract to be considered miltech for threat-modelling purposes. If your IP has military applications — whether or not you currently sell to the military — adversaries will treat you as a target.

Why Cyber Miltech is a Distinct Discipline

Three characteristics separate miltech cybersecurity from standard enterprise security:

The adversary is a standing army. Commercial companies face cybercriminals motivated by financial return. Miltech companies face intelligence services and military cyber units with multi-year operational mandates, unlimited patience, and state resources. The threat actor profiling, detection logic, and incident response playbooks appropriate for ransomware groups are inadequate against GRU Unit 74455 or FSB Centre 18.

The asset value is strategic, not financial. Data breaches cost commercial enterprises money and reputational damage. For a miltech company, the equivalent breach — CAD files for a drone guidance system, source code for a fire-control interface, personnel data on cleared staff — has consequences measured in strategic capability and human safety.

The regulatory environment is mandatory and audited. Enterprise security frameworks are largely voluntary and market-driven. Miltech cybersecurity operates under mandatory frameworks — NCCC in Ukraine, NIS2 in the EU, ITAR/EAR for US export-controlled technology, and sector-specific standards for NATO interoperability. Non-compliance carries criminal liability for individuals, not just organisational fines.

Why the Threat Landscape Hits Miltech Hardest

Who is Targeting Defence Technology Companies

Ukraine's defence technology sector faces a specific and documented adversary set. Three GRU and FSB-affiliated groups account for the majority of intrusions AmonSul has investigated in miltech clients over the past three years:

Sandworm (GRU Unit 74455) is the most operationally aggressive group active against Ukrainian targets. Known for the 2016 and 2022 power grid attacks, Sandworm has expanded its miltech targeting significantly since 2022, prioritising long-term pre-positioning in defence contractor networks ahead of destructive payload deployment. Their current TTPs emphasise living-off-the-land techniques, edge device exploitation, and Active Directory abuse — all documented in our Sandworm TTP analysis.

Gamaredon (FSB Centre 18, Unit 71330) runs the highest-volume miltech targeting programme of any Russian group, compensating for lower sophistication with persistent, automated phishing infrastructure and rapid reinfection capability. Their primary interest is personnel data, communications intercepts, and access credentials — intelligence with immediate tactical value.

APT28 / Fancy Bear (GRU Unit 26165) runs precision spear-phishing operations targeting senior personnel at miltech companies for credential theft and long-term espionage. Unlike Sandworm, APT28 rarely deploys destructive payloads — their operational mandate is collection and exfiltration.

Beyond these primary groups, miltech companies are targeted by criminal actors seeking ransomware payments (which create leverage for state actors through double-extortion), North Korean IT workers embedding in contractor supply chains, and Iranian groups with demonstrated interest in drone and missile technology.

What Adversaries Are After

The target categories ranked by frequency across AmonSul incident response engagements:

  1. CAD and engineering files — 3D models, simulation data, materials specifications, and production documentation for weapons systems and components
  2. Firmware and embedded software — Source code for guidance, targeting, and communications systems
  3. Personnel data — Security clearance holders, their family relationships, travel patterns, financial pressures — intelligence with blackmail and targeting value
  4. Communications intercepts — Email archives, internal messaging platforms, project management tools containing operational and strategic planning data
  5. Supplier relationships — Vendor lists, contract terms, and supplier technical specifications that enable supply chain attacks against harder targets
  6. Network architecture — Diagrams and configurations that support future intrusion planning

The Primary Attack Vectors

Understanding which vectors are most commonly exploited in miltech intrusions shapes where defensive investment provides the highest return:

Edge device exploitation accounts for a growing share of initial access. VPN appliances, firewalls, and email gateways are internet-facing, rarely covered by EDR, and often running software versions that lag patches by months or years. Sandworm's documented preference for Ivanti, Fortinet, and Cisco IOS XE exploitation reflects the reliable initial access these devices provide.

Spear-phishing with weaponised attachments remains effective against miltech companies because defence-related correspondence — procurement enquiries, technical specifications, partnership proposals — provides convincing lures. Gamaredon's infrastructure generates thousands of targeted lures per week using scraped company information.

Supply chain compromise exploits the trust relationships between miltech primes and their suppliers. Attacking a tier-2 or tier-3 supplier with weaker security controls often provides lateral access to the prime contractor's environment.

Credential theft from breached data exploits password reuse. Credentials exposed in commercial data breaches are systematically tested against defence contractor VPN portals, webmail, and partner access systems.

NIST CSF Mapping for Defence Contractors

The NIST Cybersecurity Framework 2.0 (released February 2024) provides the most widely adopted structure for mapping miltech security controls. The six functions — Govern, Identify, Protect, Detect, Respond, Recover — translate directly to measurable programme requirements.

Govern

CSF 2.0 elevated governance to a top-level function because security programmes without executive accountability consistently underperform. For miltech companies, governance requirements extend beyond policy approval:

  • Risk appetite statement explicitly covering nation-state adversary scenarios, not just cybercriminal threats
  • Supply chain risk management policy with mandatory security baseline requirements for suppliers with any network or data access
  • Board-level accountability aligned to NIS2 Article 20 requirements for essential entities
  • Classification policy for defence-related IP distinguishing public, internal, sensitive, and controlled/classified data

Identify

Asset visibility is the precondition for all other controls. Miltech companies consistently underestimate their attack surface because engineering infrastructure — PLM systems, CAD servers, simulation environments — lies outside traditional IT asset management.

  • Complete hardware and software asset inventory including OT/ICS/embedded systems
  • Data flow mapping showing where controlled technical data (ITAR/EAR, classified, export-controlled) is stored and transmitted
  • Third-party access inventory covering every supplier, contractor, and partner with network or data access
  • Attack surface mapping including all internet-facing assets — see our attack surface management guide for methodology

Protect

  • MFA on all remote access — VPN, webmail, partner portals, cloud platforms. Hardware tokens for privileged users
  • Network segmentation separating engineering networks (PLM, CAD, simulation) from corporate IT
  • Endpoint protection with EDR on all endpoints including domain controllers and engineering workstations
  • Patch management with SLA of ≤7 days for internet-facing systems and ≤30 days for internal systems
  • Email security including attachment sandboxing and anti-phishing training with simulated lure testing
  • Data loss prevention on engineering file repositories and communication platforms

Detect

The detection function is where most miltech security programmes have the largest gap. Standard commercial EDR detects known malware families reliably. It has significant blind spots against the living-off-the-land (LOTL) techniques that nation-state actors use to avoid detection:

  • SIEM with rules tuned to defence-sector threat actor TTPs — not generic MITRE ATT&CK coverage
  • EDR on domain controllers — commonly excluded for performance reasons; critical for detecting AD-based persistence
  • Network detection and response (NDR) covering east-west traffic, not just north-south perimeter flows
  • DNS monitoring for C2 communication detection and new domain first-seen alerting
  • Active Directory change monitoring specifically watching AdminSDHolder, Domain Admins group membership, and GPO modifications

Respond

Incident response capability for miltech companies requires higher sophistication than standard commercial IR:

  • IR plan and playbooks covering nation-state TTPs specifically: pre-positioned implants, destructive payload scenarios, supply chain compromise, intellectual property exfiltration
  • Evidence preservation procedures meeting chain-of-custody standards for potential legal proceedings
  • Regulatory notification workflows satisfying both NCCC (4-hour supply chain incident, 72-hour general incident) and NIS2 (24-hour significant incident) requirements simultaneously
  • Retainer arrangement with a specialist IR provider that has documented miltech experience — the time to evaluate an IR firm is not after an incident starts

Recover

  • Business continuity plan with tested recovery procedures for engineering infrastructure (PLM, CAD, ERP), not just IT systems
  • Offline backups of critical engineering data with tested restoration procedures
  • Communication plan for regulatory notifications and (where applicable) customer/partner notification
  • Post-incident review process feeding back to detection and protection controls

The MDR/CTI/ZTNA Stack for Miltech

Three service categories form the minimum viable security stack for miltech companies operating under active nation-state threat:

Managed Detection and Response (MDR)

MDR provides 24/7 SOC coverage with analysts who investigate alerts, perform active threat hunting, and escalate confirmed incidents to response. For miltech companies the critical differentiator is whether the MDR provider's detection logic and analyst training covers nation-state TTPs — not just the commodity ransomware playbooks that dominate commercial MDR offerings.

Miltech-appropriate MDR includes:

  • EDR management across all endpoints including domain controllers
  • SIEM with custom detection rules for the specific APT groups targeting defence technology
  • Active threat hunting using nation-state-specific hypotheses (LOTL persistence, AD backdoors, long-dwell exfiltration)
  • Integration with the CTI layer for actor-specific enrichment of alerts

AmonSul's Managed Detection and Response is built on four years of operational contact with the adversaries targeting Ukrainian miltech — threat hunting hypotheses and detection rules are derived from real incident observations, not published reports.

Cyber Threat Intelligence (CTI)

Generic threat intelligence feeds — commodity IOC lists, CVE databases, open-source reports — have limited value for miltech companies facing specific adversaries. Actor-specific CTI provides:

  • Profiled TTPs for the specific groups targeting your sector and geography
  • Infrastructure intelligence: C2 IP ranges, domain registration patterns, TLS fingerprints that enable proactive blocking ahead of known IOC lists
  • Early warning of targeting campaigns against miltech companies — attack infrastructure is often built and tested before lures are sent
  • STIX/TAXII-formatted feeds that integrate with SIEM and SOAR platforms for automated enrichment

VATRA provides intelligence specifically calibrated to the threat actors targeting Ukrainian and European miltech companies — 47+ APT actor profiles maintained from direct operational observation, updated weekly.

Zero-Trust Network Access (ZTNA)

ZTNA replaces implicit trust in network location with continuous verification of user identity, device health, and access context. For miltech companies, ZTNA is the architecture that closes the gap exploited by supply chain compromise and credential theft:

  • Identity-based access — users and devices are never implicitly trusted based on network location; every access decision is policy-evaluated
  • Least-privilege enforcement — engineering users access only the specific systems their role requires; no broad network access
  • Device health validation — access is denied from endpoints that fail health checks (missing patches, disabled EDR, unknown device)
  • Continuous session monitoring — anomalous access patterns (unusual hours, unusual data volumes, unusual destinations) trigger re-authentication or session termination

ZTNA does not eliminate all attack paths, but it significantly raises the cost of lateral movement — the stage of intrusion that converts initial access into data exfiltration or destructive capability.

NCCC Compliance for Miltech Companies

Ukraine's NCCC mandatory security requirements apply to miltech companies whose systems are classified as critical information infrastructure (CII). Classification assessment is the first step: most miltech companies with government contracts and defence production licences will classify as Category II at minimum.

What Miltech Companies Must Implement

For Category II classification, NCCC mandates:

  • Continuous security monitoring with SIEM logging aligned to defined event categories
  • Incident notification to the State Centre for Cyber Defence (SCCD) within 72 hours of detection (4 hours for supply chain incidents)
  • Annual external security audit by an NCCC-accredited firm
  • Vulnerability scanning on a defined cadence with remediation tracking
  • Approved cryptographic standards (DSTU 4145, DSTU 7564) for systems interfacing with government infrastructure
  • Personnel security measures including security awareness training and background verification for staff with access to critical systems

Category I systems (those with direct military or strategic significance) carry additional requirements including penetration testing, stricter logging retention, and tighter incident notification timelines.

Integrating NCCC with NIS2

For miltech companies with European business or EU market access, dual NCCC/NIS2 compliance is increasingly the baseline requirement. The frameworks share a 70%+ control overlap — a unified ISMS built to both standards simultaneously is substantially more efficient than sequential compliance projects. Our NIS2 and NCCC compliance mapping covers the delta requirements in detail.

AmonSul's compliance advisory practice runs miltech-specific NCCC gap assessments from scoping through audit readiness. The programme includes SCCD notification workflow design, DSTU cryptographic integration planning, and accredited auditor coordination. See the defence-tech industry page for the full service scope.

Vendor Selection Checklist: Miltech Cybersecurity Providers

Evaluating a miltech cybersecurity provider is different from selecting enterprise security software. The questions that matter are operational and intelligence-specific:

Threat Intelligence Capability

  • [ ] Does the provider maintain proprietary intelligence on the specific APT groups targeting your sector and geography — or do they resell commodity feeds?
  • [ ] Can they provide documented examples of intelligence contributing to pre-emptive defence (blocking attacker infrastructure before an intrusion attempt) rather than only post-incident attribution?
  • [ ] Are their threat actor profiles updated from direct operational observation or only from open-source reporting?

Detection Specificity

  • [ ] Are their SIEM detection rules tuned to nation-state TTPs (LOTL techniques, AD abuse, edge device exploitation) or primarily focused on commodity malware?
  • [ ] Do they have documented detection logic for the specific APT groups targeting your sector?
  • [ ] Can they demonstrate threat hunting hypotheses derived from real miltech incident experience?

Incident Response Experience

  • [ ] Have they responded to nation-state intrusions in defence technology or critical infrastructure environments — not just commercial ransomware incidents?
  • [ ] Do their IR playbooks cover pre-positioned implant scenarios, destructive payload containment, and IP exfiltration investigation?
  • [ ] Can they meet NCCC notification timelines (72-hour general, 4-hour supply chain) as part of their IR service?

Regulatory Coverage

  • [ ] Are they familiar with NCCC compliance requirements and the SCCD notification process?
  • [ ] Can they provide documentation and evidence packages suitable for NCCC Category II external audits?
  • [ ] Do they understand ITAR/EAR implications for companies with US-origin controlled technology?

Operational Model

  • [ ] Is SOC coverage genuinely 24/7 with Ukrainian or EU-based analysts — or is overnight coverage handled by an offshore team with different threat context?
  • [ ] What is the escalation path from alert to analyst to IR team? What are the documented SLAs?
  • [ ] Do they have the capability to deploy on-site for incident response, or is their engagement model remote-only?

References and Evidence

  • [ ] Can they provide references from miltech clients willing to discuss the engagement (under NDA if necessary)?
  • [ ] Do they publish original threat research — not just marketing content — that demonstrates operational depth?
  • [ ] Are their team members contributors to CERT-UA advisories or sector-specific threat sharing communities?

FAQ

What makes miltech cybersecurity different from standard enterprise security?

The adversary profile is the fundamental difference. Commercial companies primarily face financially motivated cybercriminals who avoid high-cost, high-risk targets. Miltech companies face intelligence services and military cyber units with strategic mandates that explicitly include your company. These adversaries are patient (dwell times measured in months), well-resourced (state budgets, not criminal proceeds), and specifically trained against the same targets you are trying to defend. Detection logic, incident response playbooks, and threat intelligence appropriate for ransomware gangs are largely inadequate against GRU Unit 74455.

Which APT groups most actively target Ukrainian miltech companies?

The three primary groups documented in AmonSul incident response engagements are Sandworm (GRU Unit 74455), Gamaredon (FSB Centre 18), and APT28 (GRU Unit 26165). Sandworm is the most dangerous — focused on long-term pre-positioning and capable of destructive payloads against critical infrastructure. Gamaredon runs the highest volume of miltech-targeted phishing operations. APT28 specialises in precision credential theft and long-term espionage against senior personnel. All three are actively operational against Ukrainian targets in 2025.

Is NCCC compliance mandatory for miltech companies?

Yes, for companies whose systems qualify as critical information infrastructure (CII) under Ukraine's Law 2163-IX. Most miltech companies with active government contracts, defence production licences, or systems integrated with military C2 infrastructure will qualify as Category II at minimum. NCCC compliance carries audit requirements, mandatory incident notification to SCCD, and specific technical control obligations. Non-compliance exposes both the organisation and responsible individuals to legal liability.

What does a miltech MDR deployment typically involve?

MDR deployment for a miltech company begins with an asset discovery and scoping phase (typically 1–2 weeks), followed by EDR agent deployment across all endpoints, SIEM integration with existing log sources, and custom detection rule development tuned to the specific threat actors targeting your sector. The ongoing service includes 24/7 alert monitoring, weekly threat hunting sessions, monthly reporting, and IR support when confirmed incidents are detected. A full MDR deployment for a 100–500 person miltech company typically takes 4–8 weeks from contract to full coverage.

How does ZTNA protect against supply chain compromise?

Supply chain attacks gain their effectiveness from the implicit trust that exists between a miltech prime and its suppliers. Once an attacker compromises a trusted supplier, they inherit that trust — ZTNA eliminates it. Under a ZTNA model, a supplier's access to your environment is bound to specific applications, specific data resources, and specific time windows — evaluated continuously based on the supplier user's identity, device health, and behaviour. A compromised supplier credential cannot move laterally through your network; it can only access what the specific policy explicitly permits, and anomalous session behaviour triggers re-evaluation before data can be exfiltrated.

What data do nation-state actors typically target at miltech companies?

Based on AmonSul incident response observations, the most frequently targeted data categories are: engineering files (CAD, simulation, firmware source code); personnel data on cleared staff; communications archives (email, internal messaging, project management); supplier relationships and technical specifications; and network architecture documentation. The priority varies by the adversary's operational mandate — Gamaredon focuses on personnel intelligence while Sandworm prioritises infrastructure access for potential destructive use.

How long does it take to achieve NCCC Category II compliance from a low baseline?

For a miltech company starting without an existing ISMS or formal security programme, achieving NCCC Category II compliance typically requires 6–9 months. The critical path items are: asset inventory and CII classification assessment (Months 1–2), ISMS establishment with risk assessment and core policy set (Months 2–4), technical control implementation including SIEM, EDR, and incident notification workflow (Months 3–6), and external audit preparation and execution (Months 6–9). Companies with existing ISO 27001 certification can typically compress this to 3–4 months by focusing on the NCCC-specific delta requirements.

Should a miltech company run its own SOC or use managed MDR?

For the vast majority of miltech companies — those below ~2,000 employees — building an internal SOC that can match the detection capability of a specialist MDR provider is neither economically viable nor practically achievable. A qualified SOC requires 8–12 analysts for 24/7 coverage (accounting for shifts, leave, and attrition), plus SIEM infrastructure, threat intelligence subscriptions, and continuous training. The aggregate cost typically exceeds €1.5–2M annually before one-time setup costs. More critically, internal SOC analysts rarely have the adversary-specific expertise that miltech threats demand — threat intelligence and detection logic that takes years to build cannot be hired quickly. MDR from a specialist provider with documented miltech experience provides higher detection capability at a fraction of the cost, with the option to build internal capacity over time as the security function matures.

Share
Back to blog

AmonSul Threat Intelligence Team

Threat Intelligence, AmonSul

AmonSul's threat intelligence team tracks nation-state and criminal threat actors targeting defence technology, critical infrastructure, and financial institutions across Ukraine and the EU.

Related reading

Put this intelligence to work

AmonSul's MDR and threat intelligence services are built on the same research that feeds this blog — not generic playbooks.