MAC Address: Data Point Intelligence Guide

A MAC address is the closest thing to a serial number that a network interface broadcasts for free. It is also one of the most misread artifacts in digital forensics.

Understanding the MAC Address as an intelligence artifact

A MAC address is a 48-bit layer-two hardware identifier assigned to a network interface, conventionally written as six hexadecimal octets. The first three octets form the Organisationally Unique Identifier, registered with the IEEE by the manufacturer; the remaining octets are assigned by that manufacturer. Two bits in the first octet carry meaning: the least significant bit marks group versus individual addressing, and the next marks whether the address is universally or locally administered. A MAC identifies an interface within a single broadcast domain, nothing more.

Analytically, the key variants are the IEEE registry sizes, MA-L, MA-M and MA-S, which allocate 24, 28 and 36 bit prefixes respectively and therefore change how precisely a prefix identifies a vendor. Randomised MACs, now default for Wi-Fi probing on modern mobile operating systems, set the locally administered bit and rotate per network or per session, breaking naive device tracking entirely.

Why it matters

MAC addresses matter because they persist in places IP addresses do not: DHCP lease tables, ARP caches, switch CAM tables, wireless controller logs, router configurations and forensic images of devices. In an incident they tie a specific physical interface to a specific port at a specific time, which is exactly what is needed to place a device inside a building or on a segment. The OUI also identifies hardware vendor, which helps classify unknown devices and spot equipment that should not be on the network.

What analysts actually look for

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

• Vendor identity from the OUI, distinguishing enterprise switching gear, IoT devices, virtual machine hypervisors and consumer phones on the same segment.
• Locally administered bit set, indicating a randomised or deliberately spoofed address rather than a factory-assigned one.
• Virtualisation prefixes such as those registered to VMware, VirtualBox and Xen, revealing virtual rather than physical hosts.
• Sequential addresses within one vendor prefix, suggesting devices purchased and deployed as a batch by the same organisation.
• Presence in DHCP and ARP records correlating an interface with an assigned IP and a lease time window.
• Switch port and wireless controller association placing the interface at a physical location within a site.
• Duplicate MAC observations across segments, typically indicating spoofing, cloning or a misconfigured bridge.
• Mismatch between OUI vendor and observed operating system fingerprint, a practical indicator of address spoofing.

Where the data comes from

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

• IEEE Registration Authority OUI and MA-M/MA-S listings — Authoritative vendor assignment for any prefix, including registry size and registrant organisation address.
• Wireshark manuf database — Curated, offline vendor lookup table including many well-known sub-prefix assignments and virtualisation ranges.
• macvendors and similar lookup APIs — Fast programmatic OUI to vendor resolution for bulk enrichment of log data.
• Internal DHCP server and lease logs — Authoritative binding of MAC to IP, hostname and lease window inside your own environment.
• Switch CAM tables and wireless controller logs — Physical port or access point association placing an interface at a specific location and time.
• Nmap and arp-scan on authorised networks — Live layer-two discovery correlating MAC, IP and OS fingerprint within your own broadcast domain.
• WiGLE — Relevant when the MAC is an access point BSSID rather than a client interface, giving observed locations.

A working method

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

1. Normalise the format — Convert to a single canonical representation, lowercase without separators, before comparison, since colon, hyphen and Cisco dotted forms all appear in logs.
2. Check the administration bits — Inspect the second least significant bit of the first octet, and treat locally administered addresses as randomised or spoofed rather than vendor-assigned.
3. Resolve the vendor — Look up the prefix against IEEE registries at the correct length, since MA-M and MA-S assignments require 28 or 36 bit matching to identify the true registrant.
4. Correlate with layer three — Join against DHCP leases and ARP records to bind the interface to IP addresses and hostnames over specific time windows.
5. Locate physically — Query switch CAM tables and wireless association logs to place the interface on a port, access point or floor at the time of interest.
6. Test for spoofing — Compare vendor against OS fingerprint and traffic behaviour, and look for the same address appearing in implausible places simultaneously.
7. Preserve the record — Export the underlying log entries with timestamps and device identifiers rather than relying on a screenshot of a lookup result.

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.

Pivots to these data points

• Domain Name — Human-readable address that maps to IP infrastructure via DNS.
• IP Address — Internet Protocol address identifying a device or server on a network.
• URL — Uniform Resource Locator pointing to a web resource.
• ASN — Autonomous System Number identifying a network operator on the internet.
• Subdomain — A host under a parent domain — often reveals staging, admin, and forgotten infrastructure.
• IP Range / CIDR — A block of IP addresses expressed in CIDR notation — the unit of network ownership and allocation.

Inside the platform: where MAC Address 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:

• datapoint.php?dp=dp_mac_address — Data point hub
• search.php — Advanced search, filter and pivot
• 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:

• Enrichment Runner
• Enrichment → Local
• Correlate Infrastructure
• 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:

1. Triage under time pressure. An artifact or report lands and you need a defensible read in minutes, not days. Normalise the format is the first move; the platform pre-computes the enrichment so the analyst spends the time on judgement rather than lookups.
2. Building the picture. A single indicator is rarely the story. Resolve the vendor 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.
3. Producing something actionable. Analysis that ends in a document nobody can use is wasted. Preserve the record 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 MAC Address

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

On a defence network a hardware address is an accountability primitive: it binds an interface to a switch port, an access point and a time, which is what network access control and unauthorised device detection depend on. It supports insider threat work, counter intelligence sweeps for unapproved equipment, and post incident reconstruction of which terminal touched which system. Constraints are procedural rather than technical: collection is limited to networks under your authority, association logs are personal data where they map to assigned users, and randomised addressing on modern endpoints means device counts derived from passive capture are unreliable and must not be briefed as headcount.

🕵 National intelligence

Hardware addresses appear in national intelligence work mainly through lawfully obtained device images, network logs and technical exploitation of seized equipment, where they corroborate that a specific interface was present on a specific network. They also support equipment attribution, since vendor prefixes identify manufacturers subject to export control or procurement interest. Handling rules are strict because association records tie to identifiable persons, so minimisation applies before dissemination and raw lease tables are rarely releasable. Report the vendor prefix and the observation context rather than raw addresses where the reporting purpose is equipment characterisation rather than individual identification.

👮 Law enforcement

For law enforcement a hardware address is strong corroborative evidence and weak standalone evidence. Its power is placing a device on a network at a time, via DHCP leases, wireless controller association logs and switch tables held by the network operator, all of which require a production order or equivalent when the network is not the investigator's own. Preserve native log records with timestamps and system identifiers rather than screenshots of a lookup tool. Because spoofing is trivial and randomisation is default on modern handsets, present the address as one element of a chain that includes device examination and subscriber or account records.

🔍 Private investigation and corporate security

Corporate security uses hardware addresses inside the client estate for asset inventory, rogue device detection, network access control and incident reconstruction, all of which rest on the client's ownership of the network. That is the boundary: a private actor may collect from networks the client controls, under a documented monitoring policy notified to staff, but may not capture wireless traffic in public or third party spaces to track devices or people. Employee association records are personal data with employment law implications, so retention and access must follow the client's monitoring policy and be disclosed in privacy notices.

📰 Journalism and OSINT media

Hardware addresses rarely appear in reporting directly, and should not, because they identify individual equipment and are trivially misinterpreted. Where they matter is in stories about tracking: retail and transport analytics, government sponsored wireless monitoring, and vendor claims about anonymised footfall data. Verification means understanding that vendor prefixes identify manufacturers rather than owners, that randomisation defeats most naive tracking claims, and that hashed addresses are frequently re identifiable. Never publish a specific address that could identify a source's device, and treat any leaked association log as containing personal data requiring redaction before publication or description in aggregate only.

🌍 NGO, humanitarian and human rights

Human rights and digital security organisations meet hardware addresses in two contexts: documenting wireless surveillance of protests and public spaces, and helping at risk users understand device exposure. Do no harm means never building movement traces of identifiable individuals, even to demonstrate a risk. Documentation for accountability should record the presence and capability of monitoring equipment rather than the addresses of those monitored. Duty of care extends to staff carrying devices into hostile environments, where randomisation settings, hotspot behaviour and preferred network lists all matter. Any capture undertaken for research must be aggregated and consented where individuals are involved.

🎓 University and research

Researchers use hardware addresses in mobility, network measurement and privacy studies, where the ethics burden is high because addresses are direct device identifiers. Method requires stating capture location, duration, hardware, and whether randomisation was detected, since randomisation rates changed sharply across operating system versions and invalidate cross year comparisons. Ethics approval is normally mandatory, with signage, opt out and truncation or salted hashing applied at collection rather than after. Reproducibility comes from publishing analysis code and aggregate distributions, never raw address sets, since published hashed addresses have repeatedly been shown to be reversible by brute force.

Playbook: working MAC Address 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 — Confirm authority and scope

Establish that the network or device is one you administer or are lawfully authorised to examine, and record the monitoring policy or legal instrument that permits collection. Note the retention period for lease and association logs. A good output is a short authority record naming the network, the systems whose logs you will use and the lawful basis. Stop when the authority is documented; passive wireless capture in spaces you do not control is out of scope.

Phase 2 — Normalise the format

Convert every observed address to one canonical representation, conventionally lowercase hexadecimal without separators, before any comparison. Logs present colon separated, hyphen separated and vendor dotted forms interchangeably, and case differences alone will break joins across systems. A good output is a normalised field in the case dataset with the original string retained alongside. Stop when every source system's format has been mapped and a sample join returns the expected matches.

Phase 3 — Read the administration bits

Inspect the two low order bits of the first octet: the least significant marks group addressing, and the next marks locally administered. A locally administered address is randomised or deliberately set, not factory assigned, which changes the entire interpretation. A good output is a flag on each record stating universally or locally administered, with randomised addresses excluded from vendor attribution. Stop when every address is classified; skipping this step invalidates all downstream vendor analysis.

Phase 4 — Resolve the vendor correctly

Match the prefix against the IEEE registries at the correct length, testing the 36 bit and 28 bit small and medium assignment blocks before falling back to the 24 bit large block. A naive 24 bit lookup inside a shared block attributes the device to the block administrator rather than the actual manufacturer. A good output is a vendor with the registry type recorded. Stop when the registry type is known, or the prefix is recorded as unassigned.

Phase 5 — Bind to layer three

Join the address against DHCP lease records and ARP or neighbour tables to establish which addresses it held and when, capturing lease start and end times, hostname and any client identifier or vendor class option. Hostnames set by the device frequently name the owner or the asset tag. A good output is a dated binding table. Stop when the binding covers the incident window with explicit gaps rather than assumed continuity.

Phase 6 — Place it physically

Query switch forwarding tables, port security logs and wireless controller association records to establish which port, access point or floor the interface was on at the time of interest. This is the step that turns a network artifact into a physical fact. A good output is a location and time series with the source system for each entry. Stop when the physical placement is supported by a system of record rather than by inference from address ranges.

Phase 7 — Test for spoofing and cloning

Compare the vendor prefix against operating system and service fingerprints, look for the same address appearing simultaneously on segments it cannot bridge, and check for sudden vendor changes on a port with a stable device. A good output is a spoofing assessment with the specific contradictions listed. Stop when you can state whether the address is a credible hardware assertion or a claim the host made about itself.

Phase 8 — Handle virtualisation and containers

Identify prefixes registered to hypervisor vendors and container runtimes, and check for cloned images that duplicated an address across unrelated hosts. Virtual interfaces frequently have addresses generated at instantiation rather than assigned by a manufacturer. A good output is a classification of each interface as physical, virtual or container. Stop when duplicates are explained by cloning rather than treated as conflicting evidence.

Phase 9 — Correlate across systems

Bring together endpoint management inventory, network access control decisions, certificate or supplicant identity from enterprise authentication, and the address bindings, so the interface is tied to an enrolled asset and an authenticated user where that exists. A good output is an asset and identity attribution with confidence. Stop when either the asset is identified or it is confirmed as unmanaged, which is itself the finding.

Phase 10 — Assess the privacy footprint

Where the work involves association or lease logs at scale, review what personal data is being processed, whether staff were notified, what retention applies and who can access it. Randomisation means device counts are unreliable, so avoid presenting them as person counts. A good output is a data protection note attached to the analysis. Stop when retention and access controls are confirmed against policy.

Phase 11 — Preserve evidentially

Export native log records with timestamps, source system identifiers and hashes, rather than screenshots of a vendor lookup site. Record the tool and dataset version used for vendor resolution, since registry data changes as blocks are reassigned. A good output is an exhibit bundle a second analyst could re verify. Stop when every claim in the report maps to a preserved record.

Phase 12 — Report with the limits stated

Write the finding as what it is: this interface, asserting this address, was bound to this address and observed on this port between these times. State explicitly that a hardware address does not cross routers, is spoofable, and identifies an interface rather than a person. A good output is a report that a defence expert cannot undermine by pointing out a limitation you failed to acknowledge. Stop when the limitations section is complete.

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
IEEE Registration Authority public listings	Open	Authoritative assignment records for MA-L, MA-M and MA-S blocks with registrant organisation names and addresses, published and updated by the IEEE.	Correct vendor resolution at 24, 28 or 36 bit prefix length, which is the only defensible basis for a manufacturer claim.
IEEE Registration Authority assignment search	Open	Searchable interface across all registry sizes including company identifiers and historic assignment records.	Confirms whether a prefix is a large, medium or small block before attributing a device to a company.
Wireshark manufacturer database	Open	Curated offline vendor lookup table combining IEEE registries with well known sub prefix assignments and virtualisation ranges.	Fast offline enrichment during packet analysis without disclosing the address to an external lookup service.
Internal DHCP server logs and lease databases	Licensed	Authoritative bindings of hardware address to assigned address, hostname, client identifier and lease window inside your own estate.	The primary evidential source tying an interface to network addresses over a defined time window.
Wireless LAN controller association and authentication logs	Licensed	Records of which client interface associated with which access point, when, with what signal strength and authentication identity.	Places an interface at a physical access point and links it to an authenticated enterprise identity where available.
Switch forwarding and port security tables	Licensed	Layer two forwarding entries mapping hardware addresses to physical switch ports, with ageing timers and security violation records.	Establishes the physical port an interface used, which is the strongest location evidence on a wired network.
Zeek network monitoring	Open	Structured connection and protocol logs including DHCP, ARP and wireless metadata with consistent timestamps across sensors.	Provides searchable, time bounded records of layer two activity for reconstruction without full packet retention.
Nmap and arp-scan	Open	Active layer two discovery on a local broadcast domain returning hardware address, address bindings and operating system fingerprints.	Authorised discovery within your own segment to correlate vendor against observed operating system for spoofing checks.
IETF RFC 7042 on Ethernet parameters	Open	IANA considerations for Ethernet numbers including the meaning of the group and local bits and reserved address ranges.	Normative basis for interpreting the administration bits rather than relying on tool defaults.
IEEE 802.11aq and randomisation guidance	Open	Standards work covering wireless privacy mechanisms including randomised addressing in probe requests and association.	Explains why passive device counting is unreliable and how randomisation behaviour differs by platform and state.
IEEE 802.1X and RADIUS accounting records	Licensed	Authentication and accounting logs binding a supplicant identity or certificate to a session and its hardware address.	Links an interface to an authenticated user identity, which a hardware address alone can never establish.
Endpoint management and asset inventory systems	Licensed	Enrolled device records holding hardware addresses for every interface alongside asset tag, assigned user and build history.	Attributes an observed interface to a managed asset, or confirms it is unmanaged, which is the actionable finding.
WiGLE	Registration	Crowdsourced wireless survey database mapping access point identifiers to observed coordinates, network names and sighting dates.	Relevant only where the address is an access point identifier rather than a client interface, and subject to strict authority.
NIST SP 800-86 guide to integrating forensic techniques	Open	Federal guidance on collecting, examining and reporting digital evidence including network derived artifacts.	Sets the procedural expectations for preserving lease and association records as evidence rather than as operational data.
ENISA and national data protection guidance on device identifiers	Open	Regulatory guidance treating hardware and wireless identifiers as personal data where they can be linked to individuals.	Supports the retention, notification and minimisation decisions required before any large scale association log analysis.

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 MAC Address. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

• Wireshark and tshark — Decode layer two frames and resolve vendor prefixes offline during packet analysis. Limitation: requires a capture you were authorised to take, on a segment you control.
• Zeek — Generates structured DHCP, ARP and wireless logs suitable for time bounded search. Limitation: visibility is restricted to the segments where sensors are deployed.
• arp-scan and Nmap — Enumerate live interfaces on a local segment with vendor and operating system detail. Limitation: active traffic on the local broadcast domain only, and needs authorisation.
• IEEE registry bulk files — Offline vendor resolution across all three registry sizes without external queries. Limitation: needs periodic refresh as blocks are assigned and transferred.
• Network access control platforms — Enforce and log which interfaces may join the network, with profiling and quarantine. Limitation: profiling is heuristic and readily defeated by a spoofed address.
• DHCP log aggregation in a SIEM — Centralises lease bindings for cross system correlation and retention control. Limitation: clock skew between servers routinely breaks precise time correlation.
• Wireless controller reporting — Exports association history, access point placement and signal strength for client interfaces. Limitation: retention defaults are short and often measured in days.
• Mobile device management inventories — Authoritative interface lists for enrolled devices including virtual and cellular interfaces. Limitation: covers only managed devices, which is the population least likely to be the problem.
• Kismet — Wireless survey tool recording device presence, capability and access point relationships during authorised assessments. Limitation: passive wireless collection is legally constrained outside your own premises.

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.

• Enrichment Runner — Walks the indicator set through a chosen provider in time-boxed, cursor-based batches that resume rather than restart.
• Enrichment → Local — Materialises enrichment into the local store so dashboards render from your own database instead of a live third-party call.
• Correlate Infrastructure — Builds the cross-entity link graph: shared hosting, reused certificates, overlapping registrants, repeated selectors.
• 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:

• Check the locally administered bit before anything else. Roughly every modern phone and laptop randomises its wireless address by default, and vendor attribution on a randomised address is not merely wrong, it is fabricated.
• Resolve vendors at the right prefix length. Small and medium assignment blocks share a 24 bit prefix between many companies, so a naive lookup will confidently name the wrong manufacturer for low volume equipment.
• The vendor of the chipset is not the brand on the box. Contract manufacturers and module suppliers dominate the registries, so read the result as a component supplier rather than a product identity.
• Duplicate addresses across unrelated hosts almost always mean cloned virtual machine images rather than spoofing. Check hypervisor prefixes and build timestamps before opening an incident.
• An address observed from across a router belongs to the last hop gateway, not the source device. This is the single most common misreading of hardware addresses in incident reports.
• Lease and association logs age out fast, frequently within days on default configurations. Extend retention deliberately for the systems you will actually need, and check the current setting before assuming history exists.
• Enterprise authentication accounting is worth more than the address itself, because it binds a session to a certificate or user rather than to an interface that anyone can impersonate.
• Never present passively counted addresses as a count of people or devices. Randomisation inflates counts unpredictably, and platform behaviour changes between operating system releases, so trend comparisons across years are meaningless.

Measuring whether it is working

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

• Proportion of interfaces observed on the network that map to an enrolled asset in the inventory, tracked as a measure of unmanaged device exposure.
• Median time from an unknown interface joining the network to detection and either enrolment or quarantine.
• Clock skew between DHCP, wireless controller and switch logging sources, measured periodically, since correlation accuracy depends entirely on it.
• Retention coverage: the percentage of incidents where lease and association history existed for the full investigation window rather than having aged out.
• Rate of spoofing indicators detected through vendor and fingerprint mismatch, tracked to validate that the detection is functioning rather than silent.
• Share of network evidence exhibits preserved as native log exports with hashes rather than as screenshots, sampled from closed cases.
• Number of association log datasets processed with a documented lawful basis and retention period, measured against total datasets held.

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

• MAC addresses do not cross routers, so an address observed remotely belongs to the nearest gateway, not to the distant device.
• Modern phones and laptops randomise MACs per network by default, which defeats device tracking and inflates apparent device counts.
• Spoofing is trivial on every mainstream operating system, so a MAC is an assertion by the host rather than proof of hardware identity.
• OUI lookup identifies the chipset or NIC vendor, which is frequently not the brand printed on the device casing.
• Smaller MA-M and MA-S registrations mean a 24-bit prefix lookup can attribute a device to the wrong company entirely.
• Virtual machines, containers and cloned images regularly duplicate MAC addresses across otherwise unrelated hosts.

Legal and ethical considerations

A MAC address is treated as personal data in EU guidance when it can be linked to an individual, and regulators have specifically addressed MAC-based tracking of visitors and passers-by. Collect only from networks you administer or under lawful authority, define a retention period for DHCP and association logs, and avoid building movement profiles from passively captured addresses without a clear legal basis. For evidential use, export native log records with timestamps and preserve hashes, since a vendor lookup screenshot proves nothing on its own.

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 MAC Address, 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 6 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

Can I identify a person from a hardware address?

Not from the address itself. It identifies an interface, and only records held by whoever operates the network connect that interface to an account, an asset or a person. Inside your own estate the chain is inventory, authentication accounting and lease logs. Outside it, you would need lawful process against the network operator, and even then randomisation on modern devices means the address observed may be ephemeral and unique to that network. Treat any claim that an address identifies an individual as requiring corroborating records rather than accepting it at face value.

How reliable is vendor lookup?

Reliable for the registrant of the prefix, unreliable as a statement about the product. Three issues dominate. First, small and medium registry blocks share a 24 bit prefix, so lookups that only match 24 bits attribute devices to the block holder rather than the actual company. Second, the registrant is usually the network interface or chipset manufacturer, not the brand on the device. Third, prefixes are transferred and reassigned, so old datasets return outdated organisations. Always record the registry type and the dataset version alongside the vendor name.

Does randomisation make hardware addresses useless?

It makes passive tracking of unassociated devices largely useless, which was the intent. It does not affect the evidential value inside a managed network, because once a device associates and authenticates, the network sees a stable address for that session and binds it to an identity. Modern platforms use a per network address that persists for that network, so within your estate the address remains a usable key. What breaks is counting unique devices from probe requests and correlating a device across unrelated locations.

What do I need to place a device in a building?

Records from the network operator, not from the address. On wired networks that is the switch forwarding table plus port security logs showing which physical port the address appeared on and when. On wireless it is the controller association log naming the access point, with signal strength if available. Both need accurate, synchronised clocks and retention long enough to cover the period of interest. Export the native records with hashes; a screenshot of a management console is weak evidence and is routinely challenged.

Someone spoofed an address. How do I prove it?

Look for contradictions the spoofer cannot control. Compare the claimed vendor prefix against operating system and service fingerprints from passive analysis, since a printer prefix presenting a desktop operating system stack is a clear mismatch. Check for the same address active simultaneously on segments a single device could not bridge. Review port security violation logs and sudden vendor changes on a port whose physical device did not change. Also check whether the legitimate device dropped off the network at the same moment, which frequently accompanies address duplication.

How long should we retain lease and association logs?

Long enough to investigate a typical incident and no longer, which for most organisations means ninety days to a year, set deliberately rather than left at vendor defaults of a few days. The constraint is that these records are personal data when they map to assigned users, so retention needs a documented justification, a privacy notice covering staff monitoring, and access controls. Where regulatory obligations set a minimum, follow those. Review the setting before you need it, because discovering the gap during an incident is too late.

Is capturing wireless addresses in a public space lawful?

Generally not for identifying or tracking individuals, and regulators in several jurisdictions have taken enforcement action against retail and municipal wireless analytics that did so. Passive capture of broadcast frames sits in a contested area technically, but building movement profiles from it constitutes processing personal data and requires a lawful basis, transparency and, in many cases, a data protection impact assessment. For investigative work, the answer is simpler: collect from networks you administer or under specific legal authority, and do not conduct wireless surveys to locate or follow a private individual.

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:

• IEEE 802 and the EUI-48 addressing architecture, defining the structure of hardware addresses and the meaning of the group and local bits.
• IEEE Registration Authority policies for MA-L, MA-M and MA-S assignments, which determine the correct prefix length for vendor resolution.
• RFC 7042, giving IANA considerations for Ethernet parameters including reserved ranges and the interpretation of address bits.
• IEEE 802.1X and RFC 2865 RADIUS accounting, defining the authentication and session records that bind an interface to an identity.
• RFC 2131 and RFC 8415, defining DHCP for IPv4 and IPv6 including the lease records used to bind hardware to network addresses.
• ISO/IEC 27037 and NIST SP 800-86, setting expectations for the collection and preservation of network derived digital evidence.
• GDPR Article 4 online identifiers and national regulator guidance on wireless tracking, governing when hardware addresses are personal data.
• ISO/IEC 27001 Annex A asset management and logging controls, requiring inventory accuracy and defined log retention.

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.

1. IEEE Registration Authority — IEEE. Authoritative registry of organisationally unique identifiers and company identifiers across all assignment block sizes.
2. IEEE Standards Association — IEEE. Publisher of the 802 series standards defining Ethernet and wireless addressing architecture.
3. IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters — IETF. Specification covering Ethernet address semantics including local and group bit meaning.
4. Wireshark manufacturer database — Wireshark Foundation. Curated offline vendor lookup table used in packet analysis tooling.
5. Zeek network security monitor — Zeek Project. Open source monitoring platform producing structured layer two and layer three logs.
6. Guide to Integrating Forensic Techniques into Incident Response — NIST. Federal guidance on acquiring and preserving digital evidence including network records.
7. Nmap Security Scanner — Nmap Project. Discovery and fingerprinting tool used for authorised layer two enumeration.
8. ENISA guidance on privacy and data protection — ENISA. European reference material on treatment of device identifiers as personal data.
9. ISO/IEC 27037 digital evidence guidance — ISO. International standard for identification, collection and preservation of digital evidence.
10. Wi-Fi Alliance certification and security programmes — Wi-Fi Alliance. Reference for wireless authentication and privacy features affecting client addressing behaviour.

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: resolves hardware prefixes to vendors and correlates interface identifiers with lease, association and location records. Explore the platform, or browse the rest of the library by following any tag above.