Agriculture compliance: ISO 24882, AEF 040, the Data Act & ADT

ISO 24882, AEF Guideline 040, the EU Data Act, Ag Data Transparent, and the FSMA 204 / EUDR traceability wave all ask one thing of a connected-agriculture backend: which party is this, is it authorised, and can you prove it and shut it off?

A backend gated by bearer tokens and shared, NAT'd egress IPs can't answer that. A routable, DANE-provable, owner-revocable IPv6 /128 per party can. It produces the log, the attribution and the kill-switch those frameworks want as evidence, not as a paragraph in a policy document, and it gives the sector's oldest promise, farmers own their farm data, its first checkable network fact.

What every framework is really asking

Read the connected-agriculture rules side by side and the same three questions keep surfacing, phrased in five different vocabularies:

• Identity: who or what is on the other end of this machine-to-cloud connection, and can a third party, including the farmer, verify it without trusting your word for it?
• Attribution & monitoring: what did that party do, to which destinations, and can you show a continuous record of it?
• Response: when one party turns hostile, can you contain it, provably and fast, across the whole fleet, and can the owner see it happened?

None of these is a logging problem you fix with more log lines. They are identity problems: you cannot attribute, monitor or contain an actor that has no stable, provable identity in the first place. Whisper's job here is to give every party on the cloud/IP boundary exactly that identity, then let the standard toolchain read the evidence off it.

The evidence: real and shipped

Everything this page maps to a framework is a surface that exists and answers today. Four primitives do the work; each is checkable with dig, curl, or one control-plane call.

A device-derived /128 identity

A machine or ECU already holds a hardware key: a secure-element or TPM key in the telematics gateway. Whisper derives a deterministic IPv6 /128 from that key's public SubjectPublicKeyInfo plus the 17-character equipment PIN (and an optional implement/ECU serial). The address is tenant-bound (fleet-unlinkable to an outsider), DNSSEC-anchored, DANE-EE 3 1 1 pinned, and RDAP-registered. Re-deriving from the same key and PIN yields the same /128; nothing new to store, nothing to steal that would let a scraper forge it.

# Provision the machine/ECU identity from the key it already holds (control plane, live).
# identity_public_key is the base64 SPKI of the device's secure-element / TPM key.
curl -sS https://graph.whisper.security/api/query \
  -H 'X-API-Key: whisper_live_xxx' \
  -H 'content-type: application/json' \
  --data '{"query":"CALL whisper.agents({op:\"connect\", args:{tier:\"wireguard\", identity_public_key:\"<base64 SPKI>\", vin:\"1AGCM82633A004352\"}}) YIELD op, ok, status, result, error RETURN op, ok, status, result, error"}'
# -> the deterministic /128 + a WireGuard config. Same key+PIN -> same /128 (idempotent).
#    A different PIN on the same tenant -> 409; a non-string identifier -> 400.

Per-/128 egress logs

Because each party owns a dedicated /128, every DNS lookup and connection it makes is unambiguously its, with no shared-IP noise to filter. Pull one party's trail directly:

CALL whisper.agents({op:'logs', args:{agent:'<the /128>', kind:'conn', from:'-24h'}})
# -> per-event records: timestamp, kind (dns/conn/alloc), destination, decision, bytes

whisper logs --agent <the /128> --from -24h --kind conn

One-call, owner-thrown revoke

Containment is a single call. It tears down the /128, its PTR and its DANE record worldwide at DNS-TTL speed, and the teardown is provable with the same public tools that proved the identity. Because the act is visible in public DNS, it is the accountable form of the kill-switch agriculture already knows exists.

CALL whisper.agents({op:'revoke', args:{agent:'<the /128>'}})
# after it runs:
dig -x <the /128> +short            # -> empty
curl -s https://whisper.online/verify-identity/<the /128>   # -> {"is_whisper_agent": false}

The attribution graph

Turning a raw destination into "known-bad C2" or "clean CDN" is a read-only query against the public graph API. There's no CLI subcommand, just the endpoint any tool can hit:

curl -s https://graph.whisper.security/api/query \
  -H 'X-API-Key: whisper_live_xxx' \
  --data-urlencode "q=CALL whisper.identify('185.220.101.1')"
# -> what the address is, who it belongs to, threat-intel reputation, relationships

The read-only verbs (identify, origins, walk, variants, history) run the same way, over an infrastructure-and-threat-intelligence graph of billions of nodes. That is the enrichment that turns a per-machine egress log into a detection, and the sector needs it: ransomware against food and agriculture roughly doubled in 2025 by the Food & Ag-ISAC's own count, after years in which a ransomware attack halted an equipment maker's production in planting season and an $11M ransom restarted plants behind about a fifth of US meat.

The map, at a glance

Each row is a framework, the control it asks for, and the shipped evidence that satisfies it. The deep sections below unpack each one.

ISO 24882: monitor, detect, respond, for ag machinery

ISO 24882 is the agricultural sector's product-cybersecurity standard, developed in ISO/TC 23/SC 19 with its DIS registered in October 2025, and it deliberately carries the lineage of the automotive rules (UN R155's CSMS thinking, ISO/SAE 21434's engineering lifecycle) into tractors, implements and their backends. We state its stage honestly: it is a DIS, not yet published, and it is precisely the right moment to build the evidence trail it will ask for. That interface (cloud and IP, not the implement bus) is where Whisper sits.

The three shipped primitives line up one-to-one with the three verbs the lifecycle uses:

• Monitor: the per-/128 egress log is a continuous, per-party record of every destination a machine's telematics unit or a farm-API consumer reached, with the decision and byte count. Because the identity is a dedicated address, the record needs no reconstruction from correlated application logs.
• Detect: the attribution graph turns a destination in that log into a verdict. A telematics gateway that suddenly beacons to a low-reputation host stands out because the graph knows the host, not because you wrote a signature for it.
• Respond: revoke is the containment action, provable worldwide at DNS-TTL speed, and thrown by the registered owner.

# Monitor: one machine's outbound connections over the last day
CALL whisper.agents({op:'logs', args:{agent:'<the machine /128>', kind:'conn', from:'-24h'}})

# Detect: score a destination the log flagged
curl -s https://graph.whisper.security/api/query -H 'X-API-Key: whisper_live_xxx' \
  --data-urlencode "q=CALL whisper.identify('<suspect destination>')"

# Respond: contain the compromised identity, provably
CALL whisper.agents({op:'revoke', args:{agent:'<the machine /128>'}})

AEF Guideline 040: the ISOBUS security principles

The Agricultural Industry Electronics Foundation's Guideline 040 sets out security principles for ISOBUS, the ISO 11783 implement network that rides SAE J1939 framing on CAN. Its starting observation is the one this whole vertical is built on: the 64-bit ISOBUS NAME that identifies a device on the bus is a self-declared claim, and the bus has no cryptographic way to check it.

Whisper does not put cryptography on the bus. The bus, its conformance tests and TIM functional safety stay exactly where they are. What Whisper adds is the provable counterpart at the boundary the guideline points toward: the same physical device, identified on the wire by a /128 derived from its sealed hardware key, verifiable by anyone against the IANA root. Claim on the bus, proof on the wire, and the two never interfere.

# The machine's wire identity, checked trustlessly: Whisper's API is NOT trusted
whisper verify --trustless a6f1007b9e2d30c8.<tenant>.agents.whisper.online
dnssec   pass   DNSSEC-root   AAAA, PTR and TLSA(3 1 1) all DNSSEC-validated to the IANA root
dane     pass   DNSSEC-root   served leaf SPKI-SHA256 == TLSA pin

See DANE & TLSA for the byte-for-byte pin check that stands behind that one line.

EU Data Act: the authorised/unauthorised line

The EU Data Act entered into force on 12 September 2025, and its access rights reach connected products squarely including farm machinery: manufacturers must open machine-generated data to the user's chosen third parties. That multiplies the number of parties touching the backend at the exact moment the sector is standardizing how to monitor and control them: a commercial forcing function pointed straight at identity.

A verifiable per-party identity is, quite literally, the authorised-versus-unauthorised line. An authorised third party is one that holds a /128 it can prove (via DANE and RDAP, keylessly, to you, to the farmer, or to a regulator) and that can be revoked in one call. The alternative, a pile of interchangeable bearer tokens with 365-day refresh lifetimes, cannot draw that line at all: a token authenticates a claim, never the party.

# A third party proves its identity to you (or a regulator, or the farmer): no account, no shared secret
whisper verify --trustless <the third party's /128>

# You answer "who accessed what" from attribution, not from a DPA paragraph
curl -s https://graph.whisper.security/api/query -H 'X-API-Key: whisper_live_xxx' \
  --data-urlencode "q=CALL whisper.identify('<the third party's /128>')"

The Data Act makes you open the doors; a per-party /128 is the doorway that knows who walked through and can shut on exactly one of them.

Ag Data Transparent: making the promise checkable

Ag Data Transparent is the US industry's certification for ag-data contracts, built on core principles the whole sector recites: farmers own their farm data, ag tech providers use it only with consent, and the terms are stated plainly. Certified companies display the ADT seal. What the certification cannot do, because no contract can, is prove at the network layer that the promise held.

Whisper is that missing layer. Each ag tech provider, each sanctioned consumer, each cross-brand hop is one verifiable /128; the per-identity access log is the who-accessed-what record the consent model presupposes; and a withdrawn consent has a technical teeth: revoke the party's identity and the access provably ends. The seal says the contract is fair; the network fact says the contract was honoured. Also worth knowing in this space: the EU's agricultural data ecosystem is moving the same direction, with consent platforms such as Agdatahub, Gaia-X-aligned data spaces, and the Common European Agricultural Data Space (CEADS) all presupposing exactly this kind of per-party, consent-bound identity.

# The record behind the seal: one party's access trail, per-identity, exportable
CALL whisper.agents({op:'logs', args:{agent:'<the provider's /128>', kind:'conn', from:'-90d'}})
# consent withdrawn? the teeth:
CALL whisper.agents({op:'revoke', args:{agent:'<the provider's /128>'}})

FSMA 204 & EUDR: trustworthy origin behind the records

The traceability wave is arriving on a calendar: FDA's FSMA 204 food-traceability records come due on 20 July 2028, and the EU Deforestation Regulation requires geolocated plot coordinates behind in-scope commodities. Whisper does not keep FSMA records and does not assess deforestation: those live in your traceability and compliance systems, exactly where they belong. What Whisper adds is the credibility of the origin data those records are built from.

A harvest event, a spray log, a field-boundary reading is worth what its source is worth. When the machine that produced it holds a verifiable /128, the record inherits a checkable fact: this data came from that machine, at that identity, and anyone can verify it. Attributable telemetry in; auditable traceability out.

# The traceability system verifies the reporting machine before trusting its events:
curl -s https://whisper.online/verify-identity/<the harvester's /128>
{"is_whisper_agent": true, "dane_ok": true, …}

SIEM & threat-intel export

The evidence above is pullable now via the logs op and the graph API, and it exports to Splunk, Microsoft Sentinel and OpenCTI today. The remaining exports are on the roadmap, labelled honestly so nobody plans against vapour:

Until the roadmap items land, the same records are already reachable: the exports are a convenience layer over evidence you can pull today.

What this is (and is not)

Whisper anchors one boundary: the cloud/IP interface between a machine (or a farm-API consumer) and the backend. It is deliberate about what it does not touch.

• It is not your cybersecurity management system, your FSMA record-keeping, or your deforestation due diligence. It is the identity-and-attribution layer those systems consume. It complements them; it does not replace them.
• It does not sit on the ISOBUS/J1939 bus, in TIM functional safety, or on a drone's Remote-ID air interface. Those keep their own mechanisms; a Whisper DANE-anchored identity complements them at the network layer without cross-signing.
• These platform integrations are proposed, not vendor-endorsed. Each complements the stack it names and replaces none of it. ISO 24882's stage (DIS, October 2025) is stated as-is.

Everything on this page that is described as working is checkable, today, with dig, curl and one control-plane call. Everything on the roadmap is labelled as such.

Next

• Equipment & ECU identity: how the device-derived /128 is computed from the key a machine already holds
• Equipment API-abuse cure: the same identity, applied to the harvested-grant problem at the API ingress
• Agritech integrations: where the /128 plugs into farm platforms, ISOBUS, cross-brand exchange and more