Technical Intelligence (TECHINT): Intelligence Discipline Guide

Every device carries a confession: certification filings, component markings, firmware strings and design choices. Technical intelligence reads that confession to establish what a system can actually do.

What Technical Intelligence is as a discipline

Technical intelligence is the exploitation of hardware, software and technical documentation to determine a system's capability, design lineage, provenance and limitations. Where academic and patent intelligence describe intent and theory, technical intelligence deals with the fielded article. It combines documentary exploitation of certification filings, datasheets, standards submissions and manuals with physical and logical examination of the artefact itself: component identification, board-level teardown, firmware extraction and protocol analysis. The output is a grounded capability assessment stated in engineering terms rather than marketing claims.

Sub-methods include certification and type-approval mining, bill-of-materials reconstruction, firmware and binary analysis, protocol and interface characterisation, supply provenance tracing through component markings, and comparative analysis against known reference designs. Within the cycle it is primarily a processing and exploitation discipline, converting captured or acquired material into validated technical fact that anchors judgements produced elsewhere.

Why it matters

Only technical intelligence answers what a system genuinely does at the physical layer: its actual operating bands, power, ranges, sensors, cryptography and update paths. It answers whether two products from different vendors share a hidden common design or a common contract manufacturer, whether a claimed indigenous system is rebadged imported hardware, which components create single points of failure, and what the realistic performance envelope is once engineering constraints replace vendor specification sheets.

What analysts actually look for

These are the concrete, observable signals that carry weight in this area of work:

Regulatory certification filings disclosing internal photographs, test reports, operating frequencies, power levels and antenna specifications
Component markings and part numbers on boards, resolving to datasheets that bound the system's real performance
Firmware strings, certificates, update endpoints and build metadata revealing toolchains, vendors and development origin
Protocol behaviour on documented interfaces, exposing authentication design, key handling and backward compatibility choices
Reference design lineage where a product closely follows a chipset vendor evaluation board, indicating limited in-house engineering
Manuals, service bulletins and training material specifying maintenance intervals, failure modes and operational limitations
Standards body contributions showing which vendors drive which features and which options they have implemented
Serial number and date code structures that place manufacture in time and at a specific production facility

Where the data comes from

Authoritative and openly available collection points. Always confirm licensing and terms before operational or commercial use:

FCC Equipment Authorization database — Free US certification filings with internal photos, RF test reports and user manuals for radio-emitting devices
EU declarations of conformity and notified body records — CE and Radio Equipment Directive documentation stating applied standards and tested parameters
IEEE OUI and MA-L registry — Maps MAC address prefixes to the organisation that registered them, identifying real manufacturers behind rebadged hardware
NIST National Vulnerability Database — Documented vulnerabilities, affected version ranges and CPE identifiers for fielded software and firmware components
Standards bodies: 3GPP, ETSI, IETF — Published specifications and contribution records showing feature capability and which vendors implemented what
Google Patents and Espacenet — Design detail and drawings that frequently document the engineering approach behind a fielded product
Conflict Armament Research field documentation — Published component-level tracing of recovered materiel, a model for provenance methodology and a reference dataset
Manufacturer datasheets and application notes — Authoritative performance envelopes for identified components, bounding what the integrated system can achieve

A working method

A repeatable sequence beats ad-hoc searching. This is a practical starting workflow:

Establish provenance first — Record how the artefact or document was obtained, by whom and when, because an unprovenanced sample cannot support any attribution conclusion.
Exploit documents before hardware — Mine certification filings, manuals and datasheets, which frequently answer the capability question without touching the device.
Identify components — Resolve markings, part numbers and MAC prefixes to real manufacturers and datasheets, building a bill of materials with confidence levels.
Characterise behaviour — Analyse firmware and observable interfaces in an isolated environment to establish protocols, cryptographic choices and update mechanisms.
Bound the envelope — Derive realistic performance limits from component specifications and thermal, power and antenna constraints rather than vendor claims.
Compare to references — Benchmark against known reference designs and prior samples to establish lineage, rebadging and generational change.
Report with uncertainty — State findings as bounded engineering conclusions with the evidence for each, flagging what could not be determined from the available material.

How this connects across the intelligence taxonomy

Intelligence work does not respect neat boundaries. The mission domain you are working, the disciplines you practise, and the data points you pivot on are one connected system. These are the direct relationships for this entry — every link is also a tag, so you can follow any thread across the whole library.

Applied in these mission domains

Operates on these data points

Company / Organization — A legal entity — corporation, LLC, NGO, or business.
GPS Coordinates — Precise latitude/longitude coordinates identifying an exact point on Earth — the atomic unit of GEOINT analysi
Event / Incident — A discrete real-world occurrence — protest, strike, breach, seizure — with time, place, and actors.
Facility / Site — A physical installation — plant, base, port, data centre — with a fixed footprint and function.
IP Address — Internet Protocol address identifying a device or server on a network.
Location / Coordinates — A geographic point, place, or region — the basis of GEOINT analysis.
Shipment / Bill of Lading — A consignment record linking shipper, consignee, goods, and route.
HS Commodity Code — The Harmonized System code classifying a traded good — the key to trade-flow analysis.
Vessel / Ship — A maritime vessel identified by IMO, MMSI, or call sign.
Radio Callsign — A licensed radio identifier for a station, vessel, aircraft, or operator.

Related disciplines

Academic Intelligence — Research Output, Collaboration, and Expertise
Patent Intelligence — Patents, Filings, and Innovation Signals

Inside the platform: where Technical Intelligence lives

The Quantus platform is 204 pages behind a 147-item sidebar organised into six working groups: Command (24 items), Dashboards (15), Threat Theaters (14), Intelligence Domains (15), Investigate (34), and Administration (45). This entry is not a page in isolation — it is a thread running through several of them.

The modules that matter most here:

discipline.php?d=TECHINT — Discipline hub
source-catalog.php?disc=TECHINT — Source catalogue filtered to this discipline
search.php — Company / Organization profile
ip-profile.php — IP Address profile
correlate.php — Correlation graph
cases.php — Case management

Each dashboard is local-first: it renders from the platform’s own database rather than depending on a live third-party call, so it still works when an upstream API is unreachable or rate-limited. Heavy aggregates are cached with a hard query time cap and degrade to the last good value instead of hanging the page.

Automation, playbooks and AI skills

Analysis that only happens when someone remembers to run it is not a capability. The platform ships a 30-step automation pipeline (cron.php) that collects, ingests, resolves, enriches, correlates and scores on a schedule — 25 seeders, 11 resolvers and 7 enrichment runners, all idempotent and cursor-based so a run can be interrupted and resumed without duplicating or losing work.

AI skills that apply

The 16 one-click operations in ai-skills.php are deterministic jobs, not free-text generation. The ones that matter here:

Correlate Infrastructure
DNS Audit
Threat Hunt
Detection Rules
Enrichment Runner
Summarise (Copilot)
Generate Report

Alerting closes the loop: rules in alerts.php fire on new indicators matching a saved query, so a first sighting in this area raises a notification rather than waiting to be noticed at the next review.

Feeds, data sources and the API

The collection layer runs a feed registry of free, machine-readable sources — bulk blocklists and trackers (Maltrail, IPsum, FireHOL, the full abuse.ch corpora, phishing databases, Emerging Threats, Spamhaus, DigitalSide, ThreatView), authoritative government feeds (CISA KEV, OFAC, UN and EU sanctions lists), and reference datasets (RIR allocations, ip-to-ASN and geolocation tables, MITRE ATT&CK, EPSS). collect.php pulls them server-side on a schedule; feeds.php and source-catalog.php show what is registered, what it covers and when it last ran.

Anything the platform holds is reachable programmatically. The REST API in api.php exposes 11 endpoints — status, stats, search, lookup, recent, export, bulk_check, top_threats, by_category, categories, check — and export.php streams 18 formats in bounded chunks, so a million-row export neither exhausts memory nor times out:

STIX 2.1, MISP, OpenIOC 1.1, CEF (ArcSight), LEEF 2.0 (QRadar), Zeek/Bro intel, Snort/Suricata rules, Palo Alto EDL, BIND RPZ, hosts blackhole, iptables, CSV, JSON, NDJSON/JSONL, XML.

That covers the CTI standards (STIX 2.1, MISP, OpenIOC), SIEM ingestion (CEF, LEEF, Zeek), detection engines (Snort/Suricata), and direct enforcement (Palo Alto EDL, BIND RPZ, hosts, iptables) — so intelligence developed here can be actioned in the tools you already run, without a manual reformatting step. A TAXII 2.1 server and a MISP/RSS feed are also served for pull-based sharing.

Use cases

Three ways this entry earns its keep in day-to-day work:

Triage under time pressure. An artifact or report lands and you need a defensible read in minutes, not days. Establish provenance first is the first move; the platform pre-computes the enrichment so the analyst spends the time on judgement rather than lookups.
Building the picture. A single indicator is rarely the story. Identify components turns one artifact into a network — shared infrastructure, repeated selectors, the same operator behind different names — via the correlation graph and the cross-entity link engine.
Producing something actionable. Analysis that ends in a document nobody can use is wasted. Report with uncertainty feeds the case file, the detection rule, the block list or the referral — with sourcing attached so the recipient can verify it.

Case management (cases.php), watchlists, saved searches and scheduled reports mean the work persists between sessions and survives an analyst leaving the team.

How each sector uses Technical Intelligence

The same entry is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The underlying artifacts are shared — the constraints, outputs and thresholds are not.

🎖 Military and defence

Technical intelligence in a defence context establishes what a captured, recovered or acquired system actually does, which drives countermeasure development, force protection and targeting support. The analyst determines operating bands, sensor performance, cryptographic protection, power and endurance limits, and the supply lineage of components. Products feed capability assessments, electronic warfare and signature management planning, and equipment recognition guides for deployed units. Constraints are heavy: recovered materiel must be handled under explosive and hazard clearance procedures with documented custody, and technical data on controlled items is export controlled, so sharing analysis with coalition partners requires a release decision rather than an email.

🕵 National intelligence

National technical intelligence converts acquired hardware and documentation into validated engineering fact that anchors judgements from every other discipline. Requirements typically ask whether a claimed capability is real, whether an indigenous system is genuinely indigenous, and which foreign components create dependency. Findings are usually classified because they reveal what has been acquired and exploited, so an unclassified version derived only from certification filings and open datasheets is often produced in parallel for wider dissemination. Fusion with procurement, trade and academic data turns a component list into a supply chain and a supply chain into a set of policy options.

👮 Law enforcement

Law enforcement uses technical intelligence in device attribution, counterfeit goods, illegal interception equipment and IoT-enabled crime investigations. Component identification and firmware analysis can tie seized devices to a manufacturer, a production batch or a specific configuration deployed by one actor. Evidentially, everything depends on custody and repeatability: analysis must be performed on a forensic image or documented as destructive, with hashes, tool versions and analyst identity recorded so a second examiner can reproduce it. Examination of a device that is not lawfully in your possession, or of a networked system without authorisation, exposes the investigator to computer misuse liability.

🔍 Private investigation and corporate security

Corporate teams use technical intelligence for competitor product teardown, counterfeit detection in procurement, technical due diligence and supplier verification. Certification filings and datasheets answer most questions without touching hardware. The legal boundary is contractual and statutory: reverse engineering may be restricted by licence terms, anti-circumvention provisions apply to protection measures, and trade secret law limits what may be used even when lawfully derived. Never test against a system you do not own or have written authorisation to examine. Vulnerabilities discovered in third party products should go through coordinated disclosure rather than into a client report alone.

📰 Journalism and OSINT media

Technology journalists and OSINT investigators use certification records, teardowns and firmware analysis to verify vendor claims and to expose surveillance and censorship technology. Verification standards require naming the specific artefact examined, its provenance, the tools and versions used, and what could not be determined. Publish findings that let a reader replicate the analysis on their own device, but withhold detail that functions as an exploitation recipe against deployed systems. Give the vendor a genuine right of reply and a reasonable disclosure window. Be precise about the difference between a capability existing and that capability being used against a specific person.

🌍 NGO, humanitarian and human rights

Human rights organisations use technical intelligence to document surveillance tooling, spyware, censorship middleboxes and munitions components for accountability. Analysis of a victim's device requires informed consent, minimal data extraction, secure handling of personal content and a clear explanation of the risks of publication. Do no harm means considering whether publishing an indicator will burn a detection method that protects other targets, and whether attribution exposes a local researcher. Documentation should meet a standard that a court or UN mechanism can use, with continuity records and preserved images, and staff need technical security support because this work attracts retaliation.

🎓 University and research

University researchers work on hardware security, firmware analysis and supply chain provenance. Methodology requires publishing the exact sample provenance, tool versions and analysis environment so results are reproducible, and archiving firmware images where licensing permits. Ethics review applies where devices contain user data or where testing could affect live services. Responsible disclosure timelines should be agreed with vendors before publication, and institutional legal advice is prudent because anti-circumvention and computer misuse statutes vary widely and academic exemptions are narrower than researchers assume. Cite certification identifiers and datasheet revisions precisely, since both change silently.

Playbook: working Technical Intelligence end to end

A repeatable sequence, from the moment the requirement lands to the moment a product is delivered and the case is closed out. Each phase states what you are trying to establish, not merely what to click — the point is a defensible chain of reasoning, not a checklist.

Phase 1 — Establish provenance and legal footing

Record how the artefact or document was obtained, from whom, when and under what authority, and confirm you may lawfully possess and examine it. Check export control status before any transfer or sharing. A good output is a custody record with signatures, photographs of the item as received, and a written legal basis for the examination. Stop and escalate if provenance is unclear, because an unprovenanced sample cannot support attribution and may be evidence in someone else's case.

Phase 2 — Exploit documents before touching hardware

Mine certification and type approval filings, user and service manuals, datasheets, standards submissions and regulatory declarations. These routinely answer the capability question, including operating frequencies, power, interfaces and internal photographs, without any risk to the artefact. A good output is a documentary capability profile with every figure cited to a filing or datasheet revision. Stop when the remaining questions genuinely require the physical item, which is less often than analysts expect.

Phase 3 — Non-destructive external characterisation

Photograph every surface, label, marking, connector and seal at high resolution with a scale, record weights and dimensions, and capture radiographs if available before opening anything. Labels carry regulatory identifiers that unlock certification records. A good output is a complete external record that would let another analyst identify the same variant. Stop before opening if the item may be hazardous, energetic or booby-trapped, and hand it to the appropriate specialist team.

Phase 4 — Controlled disassembly and board-level survey

Open the device in a documented sequence, photographing each stage, and survey the boards for major components, test points, debug headers and manufacturer markings. Note assembly quality, conformal coating, tamper measures and rework, all of which indicate production maturity and origin. A good output is an annotated board map keyed to a component list. Stop the disassembly at the point where further steps become destructive unless destructive analysis is authorised and documented.

Phase 5 — Component identification and bill of materials

Resolve part markings, date codes, house numbers and MAC address prefixes to real manufacturers and datasheets, recording confidence per identification. House-marked parts and removed markings are themselves findings. A good output is a bill of materials with manufacturer, part, function, confidence and the evidence for each entry. Stop when the components that gate capability are identified; exhaustively identifying passives adds little and consumes days.

Phase 6 — Firmware acquisition and static analysis

Extract firmware through the least invasive available route, hash the image immediately, and work only on copies. Identify architecture, file systems, embedded certificates, hardcoded credentials, update mechanisms and third party libraries with versions. A good output is an inventory of software components and cryptographic material with offsets recorded. Stop and record the limitation if extraction would require attacking a protection measure you are not authorised to circumvent.

Phase 7 — Behavioural and protocol characterisation

Operate the device in an isolated environment with no route to production networks, and capture its interfaces, radio behaviour, boot sequence and network protocols. Establish what it emits unprompted, what it phones home to and how it authenticates. A good output is a protocol description with captures preserved. Stop before any test that would transmit on licensed spectrum without authority or interact with a live third party service.

Phase 8 — Bound the performance envelope

Derive realistic limits from component specifications combined with thermal, power, antenna and mechanical constraints, rather than repeating vendor figures. Most published performance numbers describe best case laboratory conditions. A good output is a stated envelope with the limiting factor named for each dimension. Stop when the envelope is bounded well enough to support the customer decision; further precision usually requires instrumented testing you cannot justify.

Phase 9 — Comparative and lineage analysis

Benchmark against reference designs, prior samples and competitor products to establish whether the item is an original design, a licensed build, a rebadged import or a clone. Shared reference designs, identical board layouts and common contract manufacturers are strong lineage evidence. A good output is a lineage statement with the specific shared features that support it. Stop when lineage is established or explicitly reported as indeterminate.

Phase 10 — Supply provenance and dependency assessment

Map identified components to manufacturers, countries of origin and distribution channels, flagging controlled items, sanctioned suppliers and single points of failure. Cross-check against trade and procurement data where the question concerns diversion. A good output is a dependency map showing which components would be hardest to replace. Stop when the critical dependencies are identified and their substitutability assessed at least qualitatively.

Phase 11 — Disclosure and release decision

Before writing, decide what may be published or shared: apply coordinated vulnerability disclosure for security flaws, check export control classification for the technical data, and remove detail whose only use is replication or exploitation. A good output is a release decision recorded with the authority who made it. Stop and seek authorisation rather than assuming that open source derivation makes aggregated technical analysis freely shareable, because aggregation can itself create a controlled item.

Phase 12 — Report as bounded engineering conclusions

State each finding as a conclusion with its evidence, confidence and the method used, and list explicitly what could not be determined from the available material. Include tool names and versions, image hashes and the analysis environment so another examiner can reproduce the work. A good output survives peer review by an engineer who did not see the sample. Stop before extrapolating from one sample to a whole production run without saying that is what you are doing.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

Source register: what to collect from, and how

Sources are listed with their access model so you can plan around cost and licensing before you build a dependency on them. Open means no account required; registration means a free account or API key; licensed means paid or institutional access. Always confirm current terms — licensing changes, and a source that was free for research may not be free for commercial or evidential use.

Source	Access	What it gives you	How it is used here
FCC Equipment Authorization Search	Open	US radio equipment approvals with internal and external photographs, test reports, block diagrams, manuals and operating frequencies	Often the single richest open source on a device, frequently including photographs of the board and antenna
EU declarations of conformity and notified body records	Open	Manufacturer conformity declarations against EU directives, with harmonised standards applied and notified body identifiers	Establishes which standards a product claims to meet and which body assessed it, exposing overstated compliance
IEEE Registration Authority OUI and MA-L registry	Open	Assignments of organisationally unique identifiers used in MAC addresses and other IEEE identifier spaces	Resolves observed hardware addresses to the manufacturer or module vendor, a fast lineage indicator
NIST National Vulnerability Database	Open	Catalogued vulnerabilities with severity scoring, affected product identifiers and references to advisories	Maps identified firmware components and versions to known weaknesses without any testing
3GPP specifications	Open	Mobile network standards covering radio access, core network, security architecture and device behaviour	Determines what a cellular device must implement, bounding its capabilities and exposing non-standard behaviour
ETSI standards portal	Open	European telecommunications and radio standards including harmonised standards cited in conformity declarations	Provides the actual technical requirements behind a compliance claim, including emission and test limits
IETF RFC series	Open	Internet protocol specifications, security considerations and operational guidance across the network stack	Baseline for judging whether an observed protocol implementation is standard, custom or deliberately weakened
Manufacturer datasheets and application notes	Open	Component specifications, reference designs, pinouts, timing and typical application circuits published by semiconductor vendors	Converts a component list into a capability estimate by supplying the real performance and power figures
Conflict Armament Research field documentation	Open	Documented components, markings and supply chains recovered from weapons and improvised devices in conflict zones	Reference set for tracing commercial electronic components diverted into weapons systems
Espacenet and Google Patents	Open	Patent documents describing device architecture, circuits and algorithms with drawings and priority dates	Explains why a design looks the way it does and identifies the design owner behind an unbranded module
CISA advisories and ICS advisories	Open	Vulnerability and threat advisories covering industrial control systems, medical devices and networked equipment	Corroborates firmware findings against confirmed vendor issues and gives mitigation language for the report
Ofcom and national radio equipment registers	Open	National approvals, interface requirements and spectrum conditions for radio equipment placed on the market	Cross-checks claimed operating bands against what is lawfully permitted in the target market
MITRE ATT&CK for ICS and enterprise	Open	Structured catalogue of adversary techniques mapped to platforms, including embedded and control system environments	Frames what an observed device capability enables an adversary to do, in language defenders already use
Common Criteria portal	Open	Certified product listings with security targets, protection profiles and evaluation assurance levels	Shows what security claims were formally evaluated and, crucially, what was excluded from the evaluation scope
FCC Antenna Structure Registration and equipment test labs	Open	Registered structures and accredited test laboratory records associated with equipment authorisation filings	Corroborates deployment claims and identifies the laboratory that performed a suspect test report
Octopart or supplier catalogues	Registration	Aggregated electronic component availability, pricing, lifecycle status and datasheet links across distributors	Assesses whether an identified component is current, obsolete or available only through grey channels

Prefer sources that publish a methodology and a revision history. A dataset that changes silently is a liability in any product that has to survive challenge.

Tooling

Tools commonly used against Technical Intelligence. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

Ghidra — Open-source reverse engineering suite with decompilation across many architectures; capable and free, with a steep learning curve and slow analysis on large firmware.
binwalk — Identifies and extracts embedded file systems and compressed blobs from firmware images; fast triage, prone to false positives on encrypted or packed images.
Firmware analysis frameworks such as FACT or EMBA — Automates extraction, component identification and known-vulnerability matching; good coverage breadth, but results always need manual verification.
Wireshark — Captures and dissects network and radio-derived protocol traffic; excellent dissectors for standard protocols, limited on proprietary or encrypted links.
Logic analysers and oscilloscopes — Capture bus traffic and timing on UART, SPI, I2C and JTAG; essential for hardware interfaces, requires physical access and careful probing to avoid damage.
X-ray and computed tomography imaging — Reveals internal construction, die counts and tamper measures without opening; expensive and usually only available through a specialist facility.
Optical microscopy and die imaging — Reads component markings and, with decapsulation, die identifiers; decapsulation is destructive and irreversible, so it must be authorised in advance.
Software bill of materials tooling such as Syft or CycloneDX generators — Produces structured component inventories from extracted filesystems; only as good as the metadata present in the image.
QEMU and emulation harnesses — Runs extracted firmware for dynamic analysis without the physical device; peripheral emulation gaps often prevent full boot on embedded targets.
Faraday enclosures and RF test equipment — Contains emissions during behavioural testing so no unlawful transmission occurs; costly, and shielding must be verified rather than assumed.

AI skills and automation in detail

These are deterministic jobs with defined inputs and outputs, not open-ended prompting. Each is idempotent and cursor-based: interrupt one and it resumes where it stopped rather than duplicating work or losing progress.

Correlate Infrastructure — Builds the cross-entity link graph: shared hosting, reused certificates, overlapping registrants, repeated selectors.
DNS Audit — Bulk-resolves A/AAAA/MX/NS/TXT/CNAME/SOA records and stores them as observations, building passive DNS from your own collection.
Threat Hunt — Runs saved hypotheses against the corpus and surfaces what matches, with the query preserved as a versioned artifact.
Detection Rules — Generates YARA, Sigma and Snort/Suricata logic from the selected indicators, ready to deploy.
Enrichment Runner — Walks the indicator set through a chosen provider in time-boxed, cursor-based batches that resume rather than restart.
Summarise (Copilot) — Produces a narrative summary beside the underlying records. It explains; it never creates indicators or assigns attribution.
Generate Report — Assembles a sourced product from the current case or query, with provenance attached to each element.

A note on the boundary: the only skill that involves a language model is Summarise (Copilot), and it writes prose about records that already exist. Nothing else on this list involves generation of any kind. No indicator, relationship or attribution in the platform originates from a model. See the full skill list.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

The certification filing usually beats the teardown. Regulatory photographs, test reports and manuals answer most capability questions in an afternoon, with no custody risk and no destruction, yet analysts routinely open a device before checking whether the regulator already published its internals.
House-marked and remarked components are a finding, not an obstacle. Deliberately obscured part numbers indicate either counterfeit sourcing or an attempt to hide a dependency, and either conclusion is often more valuable than the identity of the part.
Vendor specifications describe best case laboratory conditions. Real envelopes are set by thermal dissipation, power budget, antenna efficiency and duty cycle. Always name the limiting factor rather than repeating a headline range you cannot support.
One sample is one sample. Production runs vary, batches change suppliers, and captured items may be modified or degraded. State the variant, date codes and observed condition, and be explicit when generalising to a fleet from a single artefact.
Hash before you touch. Image firmware and record the hash before any analysis, because the difference between an examined image and a modified one is the whole of your credibility if the work is ever challenged.
Shared reference designs explain more apparent relationships than espionage does. Two unrelated products can look nearly identical because both used the same chipset vendor's evaluation board, so lineage claims need features that are genuinely discretionary.
Decide the disclosure boundary before you write. Detail that helps a defender identify and mitigate is publishable; detail whose only use is replication or exploitation is not, and once written into a draft it tends to survive into the final document.

Measuring whether it is working

Capability claims should be falsifiable. These are the measures that show whether work on Technical Intelligence is producing anything, and they are worth baselining before you change process or tooling.

Proportion of capability questions answered from documentary exploitation alone, without physical examination, which measures efficiency and reduces custody risk.
Reproducibility rate, measured by whether a second examiner following the recorded method and tool versions reaches the same findings.
Component identification confidence distribution across delivered bills of materials, reported rather than hidden behind a single figure.
Time from artefact receipt to first actionable capability statement, tracked against the requesting unit's decision deadline.
Number of countermeasure, procurement or mitigation decisions materially changed by a technical intelligence finding rather than merely informed by it.
Rate of findings later contradicted by a further sample or by vendor documentation, tracked as a calibration measure.
Compliance rate for export control classification and disclosure review completed before any external sharing of technical data.

Beware of measuring volume alone. Indicator counts and report counts rise easily and say little; time-to-attribution, proportion of findings that survive review, and how often a product changed a decision say a great deal.

Common pitfalls

Assessing capability from marketing specifications, which describe best-case laboratory conditions rather than fielded performance
Assuming a single sample is representative when production variants, regional SKUs and firmware versions differ materially
Confusing the brand on the case with the actual designer or manufacturer, which contract manufacturing routinely separates
Analysing firmware on a networked machine, contaminating the sample and potentially alerting the vendor or operator
Ignoring that certification filings may cover a different hardware revision than the unit in hand
Treating the presence of a capable component as proof the capability is enabled in shipped firmware

Legal and ethical considerations

Acquire samples lawfully and document the chain of custody. Reverse engineering is permitted in many jurisdictions for interoperability and security research but is constrained by contract terms, anti-circumvention provisions and trade secret law, so check the applicable regime before starting. Technical data on controlled items is subject to export control, and merely sharing detailed analysis with a foreign national can constitute a controlled transfer. Publish vulnerabilities through coordinated disclosure, and never test on systems you do not own or have written authorisation to examine.

Data integrity: no fabrication, no drift, no hallucination

Intelligence that cannot be traced back to a source is not intelligence, it is assertion. Everything in this entry — and everything in the platform behind it — is built on a small number of non-negotiable rules.

Provenance on every record

Every indicator carries the source that supplied it, a first-seen and last-seen timestamp, and a sighting count. Where several feeds report the same artifact, each contribution is recorded separately rather than collapsed, so you can see whether a finding rests on one source or twelve. Source attribution travels with the data into every export, so a recipient can audit a claim without asking you for the working.

Nothing is invented to fill a gap

If the platform has no data for Technical Intelligence, it says so. Empty is displayed as empty — never padded with plausible-looking placeholder values, sample records or illustrative examples that a reader might mistake for observations. A dashboard with no rows is a true statement about collection coverage, and it is treated as a gap to close, not a blemish to hide.

Scoring is deterministic and reproducible

Threat scores, reputation grades and risk tiers are computed from stated inputs with fixed weights, not estimated. The same inputs always produce the same output, and the formula is visible rather than a black box. Aggregates are cached with an explicit time-to-live so a figure on screen is never silently stale — and when a heavy query exceeds its time budget the platform serves the last known-good value and labels it, rather than inventing a fresh number or hanging.

Where AI is used, and where it is not

Language models summarise and explain. They do not create indicators, assign attribution or manufacture relationships. No IP address, wallet, hash or identity in the platform originates from a model — every one is ingested from a named feed, resolved from a reference dataset, or entered by an analyst with a source recorded. Copilot output is presented as narrative alongside the underlying records, never in place of them, so a reader can always check the summary against the evidence.

Guarding against drift

Enrichment is additive and timestamped rather than overwriting. Reference data — sanctions lists, allocations, taxonomies — is re-synchronised from the authority on a schedule instead of being edited in place, so local copies cannot quietly diverge from the source of truth. Attribution is recorded with a confidence level and the reporting it rests on, and inferred relationships are labelled as inferred. When a source retracts or corrects, the correction propagates rather than leaving a stale assertion behind.

What this means for you

You can put a finding from this platform in front of a regulator, a court, a board or a partner agency and show where each element came from. That is the standard the tooling is built to — because in this work, being confidently wrong is more damaging than being usefully uncertain.

By the numbers

The taxonomy this entry belongs to is not a marketing list — it is the actual structure of the platform: 52 mission domains, 52 intelligence disciplines and 65 data points, each with a live dashboard behind it. Supporting that: 18 indicator types, 14 playbooks, 16 AI skills, 18 export formats and a 30-step automated pipeline.

This particular entry connects directly to 10 data points, 10 mission domains, 2 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

Is reverse engineering legal?

It depends on jurisdiction, on how you obtained the item and on what you do with the results. Many jurisdictions permit reverse engineering for interoperability, security research or where the item was lawfully acquired, but licence terms, anti-circumvention provisions and trade secret law all impose limits, and academic or research exemptions are narrower than commonly believed. Circumventing a technological protection measure is separately regulated in several regimes. Get the legal position in writing before you start, record how you obtained the sample, and never examine a device or system you do not own or have written authorisation to test.

How do I identify a component with obscured markings?

Work from context rather than the marking. Package type, pin count and footprint narrow the family; position in the circuit and connected passives indicate function; board silkscreen references and test points often survive when the chip marking does not. Date codes on neighbouring parts bound the assembly period. Power rails, crystal frequencies and bus behaviour observed with a logic analyser identify the interface standard. Where authorised, X-ray imaging reveals die size and bond wire count. Record the identification as inferred with its confidence, and treat the obscuring itself as a reportable finding.

What do I do if I find a vulnerability in a third party product?

Follow coordinated disclosure. Report it to the vendor or to a national coordinating body such as a CERT, agree a remediation window, and hold publication until it expires or a fix is available. Document the report and the timeline. Do not include a working exploit in an intelligence product, and do not test the flaw against any system you do not own. If the product is used in critical infrastructure or medical settings, escalate through the relevant national authority as well. Where a vendor is unresponsive, the coordinating body, not the analyst, should decide on publication.

Can technical analysis of a foreign device be shared with allies?

Not automatically. Technical data relating to controlled items is itself controlled under export regimes such as ITAR and dual-use lists, and disclosure to a foreign national, even inside your own country, can constitute an export. Aggregating open source technical detail can also create a controlled data set even though each element was public. Obtain a classification and release determination before sharing, name the recipient countries explicitly in the approval, and keep an unclassified, releasable version derived only from published certification and datasheet material for wider dissemination.

How much can I conclude from firmware alone?

A great deal about software composition and configuration, and less than you would like about physical performance. Firmware gives you architecture, libraries with versions, certificates, update mechanisms, hardcoded credentials, supported hardware variants and often the manufacturer's own diagnostic strings. It does not tell you transmit power, antenna gain, thermal endurance or sensor sensitivity, all of which are physical. Firmware also frequently supports hardware options that are not fitted in the sample, so a capability present in code is a possibility rather than a confirmed feature of the item in front of you.

How do I keep the analysis environment safe?

Treat every unknown device as hostile and every unknown firmware image as malicious. Work on an isolated network with no route to production, use a dedicated workstation that is rebuilt between examinations, contain radio emissions in a verified shielded enclosure so you never transmit unlawfully, and analyse firmware in a disposable virtual machine. Keep the original artefact and the master image read-only and work on copies. Record the environment configuration in the report, because the credibility of behavioural findings depends on the reader knowing what the device was connected to.

What is the difference between technical intelligence and digital forensics?

Purpose and audience. Forensics establishes what happened on a specific device to an evidential standard for a specific proceeding, with strict continuity and repeatability requirements. Technical intelligence establishes what a class of system can do, to inform decisions about capability, countermeasures and supply chains. The methods overlap heavily and both require custody discipline, but a technical intelligence product generalises from the artefact while a forensic report deliberately does not. When an item may become evidence, apply forensic standards first and derive the intelligence product from the forensically sound record.

Standards, frameworks and further reading

Work that references a recognised framework is easier to defend, easier to hand over, and easier for a partner to consume:

ISO/IEC 27037 on identification, collection, acquisition and preservation of digital evidence, which sets the custody baseline when an artefact may become evidence.
Common Criteria (ISO/IEC 15408), which defines security evaluation, protection profiles and the scope limits that certified claims actually cover.
FCC Part 15 and equivalent national radio equipment rules, which determine permitted emissions and produce the certification record analysts exploit.
EU Radio Equipment Directive and CE conformity assessment, which mandate declarations of conformity and technical documentation for products placed on the EU market.
ISO/IEC 29147 and 30111 on vulnerability disclosure and handling, defining the coordinated disclosure process for findings in third party products.
NIST SP 800-161 on cyber supply chain risk management, which frames component provenance and counterfeit risk assessment.
Wassenaar Arrangement dual-use control lists and national export regimes, which govern transfer of technical data derived from controlled items.
SPDX and CycloneDX software bill of materials specifications, which standardise how component inventories are expressed and exchanged.

References

Primary sources and authoritative references for this entry. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

Equipment Authorization Search system — US Federal Communications Commission. Public repository of radio equipment approvals including internal photographs, test reports and manuals
National Vulnerability Database — US National Institute of Standards and Technology. Catalogue of known vulnerabilities with product identifiers and severity scoring
IEEE Registration Authority — IEEE Standards Association. Authoritative assignment of organisationally unique identifiers used in hardware addressing
3GPP specification series — 3rd Generation Partnership Project. Mobile network standards defining required device and network behaviour
Common Criteria certified products list — Common Criteria Recognition Arrangement. Evaluated products with published security targets and assurance scope
ICS and product security advisories — US Cybersecurity and Infrastructure Security Agency. Confirmed vulnerability advisories covering embedded, industrial and networked equipment
Cyber Supply Chain Risk Management practices, SP 800-161 — US National Institute of Standards and Technology. Framework for assessing component provenance, counterfeit and supplier risk
Field documentation of components in recovered materiel — Conflict Armament Research. Documented commercial component supply chains traced from weapons recovered in conflict
MITRE ATT&CK knowledge base — MITRE. Structured adversary technique catalogue used to express what a device capability enables
Radio Equipment Directive guidance — European Commission. EU conformity assessment requirements producing declarations of conformity and technical files

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this entry: correlates certification filings, component data and firmware findings into a single capability record per system. Explore the platform, or browse the rest of the library by following any tag above.