This blog covers three things: what the CRA actually demands of embedded manufacturers, why most of the security approaches you have already evaluated are the wrong tool for the job, and what purpose-built kernel-level enforcement looks like in practice.
Exein's platform brings together three components. Analyzer does static analysis: it scans firmware for CVEs, generates SBOMs, and surfaces policy gaps inside your CI/CD – and keeps monitoring after release, rescanning against newly published CVEs. AI Compliance (currently in beta) maps your product against the CRA, RED and adjacent frameworks and helps generate the evidence your compliance team needs to prepare a technical file. And Exein Runtime — whose flagship agent, Photon, is the subject of this article – is kernel-native enforcement that blocks malicious behavior before it executes.
The EU Cyber Resilience Act, in three numbers
The CRA is not a whitepaper. It is enforceable regulation with deadlines, disclosure obligations and penalties, and the clock is already running: Article 14 reporting obligations apply from September 2026, with full application landing in December 2027 — if it is not shaping your next product revision, you are already behind. Three numbers orient the whole conversation.
KEY DEADLINES
Sep 2026
Article 14 reporting obligations apply
Dec 2027
Full application of the CRA
The reporting duty lands first — September 2026, not 2027 — and it is the deadline that directly justifies runtime enforcement.
ARTICLE 14 REPORTING CADENCE
24h early warning
72h full notification
14d final report
For actively exploited vulnerabilities, Article 14 sets a reporting sequence to ENISA and national CSIRTs: early warning in 24h, full notification in 72h, final report in 14d.
MAXIMUM PENALTY
€15M / 2.5%
Whichever is higher of fifteen million euro or 2.5% of global annual turnover. For a mid-size manufacturer, this is company-level risk.
WHAT THE REGULATION ACTUALLY REQUIRES
01 Secure by default at first boot
02 Vulnerability handling for support period (5+ yrs)
03 Security updates delivered to field devices
04 Structured, tamper-evident audit logs
05 Risk assessment before market placement
Takeaway: The question is not whether — the question is how.
eBPF for observation. LSM for enforcement.
The kernel already contains everything needed to do this properly. Two mature subsystems — eBPF for observation, Linux Security Modules for enforcement — combine to give you the flexibility of sandboxed, verifier-checked programs and the authority to allow or deny an operation, in the same place. The mechanism Photon depends on — eBPF attaching to LSM hooks (BPF LSM) — landed in kernel 5.7. Photon standardizes on 6.12+ because that's where the capability is mature, stable, and backed by long-term support, giving us a dependable enforcement surface rather than an early-stage one.
EBPF
Sandboxed programs inside the kernel
Run programs in the Linux kernel with no kernel module, no recompile, no reboot. Hook every syscall, file op, fork and packet. Verifier guarantees safety — no crashes, no infinite loops.
LSM
The kernel's mandatory access control layer
SELinux and AppArmor run on LSM hooks. Framework in kernel for >20 years. Hooks intercept operations before execution. eBPF-LSM combines eBPF portability with LSM authority.
THE STACK
Application (USER SPACE)
↓
LSM hooks (ENFORCEMENT POINT)
↓
eBPF program (POLICY LOGIC)
Linux kernel 5.7+ · BTF (VERIFIER)
A SINGLE EVENT, TRACED
execve("/bin/sh") EVENT
↓
LSM hook fires INTERCEPT
↓
eBPF policy eval DECISION
↓
return EPERM · denied BLOCKED
Takeaway: The decision is enforcement — not telemetry.
How Photon works: the pre-emptive enforcement loop
Photon functions as an inline kernel-level security agent designed specifically for embedded systems. Its architecture centers on four core pillars. It operates behaviorally, runs directly within execution flows, maintains a minimal footprint, and offers broad hardware compatibility, addressing the precise constraints of edge environments. The defining feature is its pre-emptive inline execution: whereas traditional telemetry tools merely issue post-compromise alerts after malicious code executes, Photon neutralizes the operation before execution can occur.
STEP 01
Kernel event
A process tries to exec a binary. A file tries to be written. A socket tries to connect. Thousands of times a second.
STEP 02
eBPF hook fires
Photon's program is attached to the relevant LSM hook. It fires synchronously, in kernel context, before the operation proceeds.
STEP 03
Policy check
Who is trying to do what? Is this process allowed to exec this binary, this uid to write this path? Policy is fast and in-kernel.
STEP 04 · THE KERNEL DECIDES
04a · ALLOW · return 0
Action is within policy. The kernel allows the operation. Negligible overhead observed by the application.
04b · DENY · return EPERM
Kernel rejects the syscall. Operation never executes. A structured event is emitted: process, pid, uid, args, timestamp.
no userspace agent · no process to kill · the decision happens in kernel space, before control returns to any application
Takeaway: The attacker's payload never runs.
CRA compliance, article by article
This is where the architecture pays off. Each of Photon's properties maps onto a specific CRA obligation — not by coincidence, but because the regulation and the enforcement model are asking the same question.
Annex I, Pt I
No known exploitable vulnerabilities at release (via Art. 6 / Art. 13)
Analyzer scans before ship · Photon enforces from first boot
Pre-release assurance and runtime enforcement working together as one continuous control surface.
Annex I, Pt I
Secure-by-default configuration (via Art. 6 / Art. 13)
Deny-by-default behavioral policy at first boot
Unnecessary syscalls blocked, unused file paths restricted, unapproved network connections denied — before any user touches the device.
Article 14
Reporting of actively exploited vulnerabilities
Every violation generates a structured, timestamped event
Article 14's reporting sequence to ENISA and the national CSIRT — early warning within 24 hours, full notification within 72 hours, final report within 14 days of a fix — is backed by an automatic, timestamped audit trail available the moment forensics is required.
Annex I, Pt I
Provision of security updates (via Art. 6 / Art. 13)
OTA policy files under 100 KB — not full firmware images
Update the security posture of 50,000 devices in the field without a firmware-upgrade campaign.
Annex I
Logging and monitoring
Signed, timestamped events exportable to SIEM, syslog or our dashboard
Splunk, IBM QRadar, custom — your forensics team has everything it needs on day one.
Takeaway: Built for compliance from the ground up.
Deployment reality: where Photon runs
The question that always comes up here is simple: can it actually run on my hardware? For most modern industrial and embedded builds, the answer is that you are very likely already there. Standard Photon needs a Linux kernel ≥ 6.12 with eBPF-LSM enabled, CONFIG_DEBUG_INFO_BTF=y, and ≥ 64 MB of RAM — which recent Yocto and Ubuntu Core images already ship with. For older kernels or SoCs without BTF, the runtime family reaches all the way down to Linux 2.6.
EXEIN RUNTIME FAMILY
Exein Photon
Linux ≥ 6.12 · eBPF-LSM
Next-generation agent for modern Linux systems.
Exein Pulsar
Linux ≥ 5.15 · eBPF
The original eBPF agent for previous kernel generation.
Exein Lite
Linux ≥ 2.6.37 · no eBPF
Ultra-lite mode for older kernels without eBPF.
Exein IDF
ESP-IDF · ESP32
For microcontroller-class ESP32 targets.
VALIDATED HARDWARE & SOC ECOSYSTEMS
NXP i.MX 8 · 9
Industrial gateways, telematics, medical devices
Lanner Edge Inference (Intel Arrow Lake)
Edge AI, robotics, smart cameras
Raspberry Pi CM4 · 5
Compute modules and reference builds
Qualcomm QCS · Snapdragon
Vision systems and industrial HMI
Renesas RZ/G · RZ/V
Automotive and factory automation
Grinn AstraOne SBC-1680 · DEEPX
Compute-intensive edge AI workloads
INTEGRATION PATHS
PATH 01 · BUILD-TIME
Yocto layer
Drop meta-exein-runtime into your build. Policy defined in bitbake recipe. No new toolchain.
PATH 02 · RUNTIME DEPLOY
Single binary + policy file
Deploy via OTA or SSH alongside existing firmware. Zero build-system changes.
PATH 03 · CI/CD GATE
Analyzer in pipeline
Analyzer runs in pipeline; Photon policy validated before image promotion. Shift security left.
Takeaway: If you ship modern Linux systems such as Yocto or Ubuntu Core, you're very likely already there.
Five things to walk away with
01
CRA is not optional, and the first deadline is 2026.
Article 14 reporting obligations apply from September 2026, with full application in December 2027. Your next product revision needs to address Annex I and Article 14 — if you are not in the design conversation now, you will be in a fire drill later.
02
eBPF–LSM gives you enforcement, not just telemetry.
The kernel already has the hooks: eBPF programs attached to LSM hooks can allow or deny a security-sensitive operation, verifier-checked and portable across kernel versions.
03
The edge needs an embedded-native runtime.
Lightweight, portable, works air-gapped, runs in-kernel with verifier-guaranteed safety — viable on 64 MB of RAM and the constrained silicon that defines the real edge market.
04
Photon enforces policy before the syscall completes.
Behavioral policy is evaluated inline, in kernel space, and the operation is allowed or denied before control returns to the application — no userspace agent, no process to kill.
05
Exein Solutions: Analyzer and Runtime for the CRA lifecycle
Analyzer covers pre-release assurance — CVE scanning, SBOM generation and policy-gap evidence before an image ships. Runtime enforces behavioral policy on the device, and its structured, timestamped telemetry supplies the audit trail behind Article 14 reporting: the 24-hour early warning, the 72-hour notification and the 14-day final report. Those are two parts of a wider obligation — conformity assessment, technical documentation, risk assessment and the support-period vulnerability-handling process still sit alongside them in a complete CRA programme.
Built by you, trusted by your customers, secured by Exein.
If any of this maps onto your roadmap or your compliance timeline, there are three concrete ways to go further — no commitment required.
01 · Free firmware scan
Submit a firmware image through Exein Analyzer for a full CVE, SBOM and policy-gap report.
02 · Book a live Photon demo
Watch attacks blocked in real time on embedded hardware. See the LSM hook fire.
03 · Talk to the team
Bring your SoC, kernel version and build system — we'll walk through a Photon integration for your device.
