Aarloven
How it works
How it works, in full.
The questions buyers ask, the four parts of the sealed room that answer them, what you can check yourself, and what works today.
The brief in eight lines.
- For
- Buyers of connected hardware and software in Norway and the EEA, and the vendors that sell to them
- What is checked
- Sealed samples of a delivery: traffic captures, the firmware or update package, the software bill of materials
- Against what
- Criteria agreed before delivery, each listed with the clauses it relates to: EN 303 645, EN 18031, CRA Annex I, GDPR Chapter V
- Who decides
- Fixed checks first. An offline open-weights model can only flag items for review. A named expert signs every receipt (next, with design partners)
- Where it stands
- A working sealed room on AWS in Stockholm. The device checks, the model and the expert step are what we build with design partners
- What it is
- An acceptance service; CE marking stays with the manufacturer and its notified body. A receipt is a test result on a sample
- Your data
- Samples are processed in the EU (AWS Stockholm), covered by AWS's Standard Contractual Clauses and EU-US Data Privacy Framework certification.
- Who we are
- Aarloven, in Oslo
Three questions buyers face.
01 · Data
“Where does this device send its data?”
Devices and their apps talk to cloud services outside your view. Under the EU Data Act, sellers must say what data a product generates and whether it is kept on the device or a remote server. Checking it is still up to you.
Source: EU Data Act, Article 3
02 · Samples
“Can we test it with the samples kept private?”
Captures from real devices can hold personal data. Sending them to a vendor or a lab outside the EEA raises GDPR Chapter V questions: weeks of paperwork, or a test that gets skipped.
Source: GDPR, Articles 44–49
03 · Proof
“What exactly was checked, and against what?”
The radio equipment rules (from August 2025) and the Cyber Resilience Act (manufacturers' reporting duties since September 2026, most other duties from December 2027) make importers answer for the security of what they sell. Auditors ask what was tested, against what bar, with what result.
Sources: Regulation 2022/30, Cyber Resilience Act
One sealed room, four parts.
Everything runs inside an AWS Nitro Enclave in Stockholm: diskless, login-free. Only the room opens samples; anyone else would need a change to the room's key rule. By default we keep hashes instead of samples.
With you · EN 303 645, EN 18031, CRA, GDPR
Criteria, agreed first
Buyer and vendor agree what each delivery must do before it ships. Every result is per criterion, with the clauses it relates to, as a test result on a sample.
Today · AWS KMS
Sealed samples
You seal samples with a sealer you run yourself, before they leave you. AWS KMS releases the key only to the room's measured code. Next: changing that rule is published in our daily public log.
Next · offline, open-weights
Fixed checks, then an offline model
Rules decide first: where the traffic goes, known vulnerabilities, signed firmware. An open-weights model runs offline in the room and can only flag items for review; the fixed checks decide pass or fail.
Next · on every receipt
A named expert signs
The expert you designate adds a separate signature alongside the receipt. The receipt says which items a machine checked and which a person did.
Only the signed receipt leaves the room.
A result for each criterion, with fingerprints of the samples, signed inside the room and vouched for by AWS's hardware. Buyer and vendor get the same copy. Key releases are logged by AWS. Next: key-rule changes go into our public daily log.
What you can check yourself.
- You seal the samples
- You seal samples on your own machine with a small, versioned sealer. Before sealing, it checks that it is talking to our sealed room running the exact published code, and that the answer is fresh. You check the sealer's fingerprint against the one in your contract.
- What we can see
- By default we keep fingerprints (hashes) of your samples instead of the samples. Next: an expert sees the samples themselves only with your written consent, and that consent is recorded in the receipt.
- Receipts you can check
- Each receipt is signed inside the room with a key that AWS hardware vouches for. You verify it offline, on your side, with the Aarloven verifier and your own copy of the AWS root certificate.
- Tied to what you received
- Next: for supported device types, a separate signed record links the samples to the units you received, for example through the firmware fingerprint you read on the device. We start with device types where this can be checked.
- A public daily log
- Live since 12 Oct 2026: a signed entry every day in a public git repository. Anyone can mirror it, and a deleted or altered past entry shows up. Next: every key-rule change and receipt fingerprint written into it.
- Tested on real hardware
- The full chain has run on real AWS Nitro Enclaves in Stockholm: real attestation, key released only to the published code, receipt verified offline. Machines were deleted after each run.
Working today, and next.
Working in the prototype
- The room runs in Stockholm (EU)
- The key is released only to the room (AWS KMS)
- Seal samples with a sealer you run yourself
- The sealer checks the room before sealing
- A changed package is refused
- Tests decided by code
- Receipt signed in the room, vouched for by an AWS hardware document
- Receipts anyone can verify offline
- Key releases are logged by AWS
- Published room code
Next, with design partners
- Device checks: traffic, known vulnerabilities, signed firmware
- An offline open-weights model that only flags
- A named expert's signature on every receipt, as a separate signature
- Samples tied to the units you received
- Key-rule changes and receipt fingerprints in the daily public log
How each was checked: the security brief. Two receipts from the earlier prototype: the receipts.