Company
About Orionyx
A Lithuanian company working on the airspace problem that conventional air defence was never built for.
Why we exist
Air defence was built around a scarce, expensive, fast threat. Everything in it — the sensors, the effectors, the doctrine, the budget lines — assumes an adversary who arrives in small numbers and costs a fortune to field.
That assumption no longer holds. The threat that now matters at a substation, a port or a stadium is slow, small, cheap and available in quantity. It is bought rather than built, flown by someone with an afternoon of practice, and replaced without a procurement cycle when it’s lost.
Almost none of the existing architecture answers it. A system designed to see a fighter at range filters out a quadcopter as clutter. A missile that intercepts reliably costs a thousand times what it destroys. And the legal framework that governs who may act, and when, was drafted before any of this existed.
Orionyx exists to work in that gap: detection tuned to what’s actually flying, responses proportionate to what’s actually at stake, and concepts that survive contact with the law and the budget.
Why Lithuania
Being domiciled on the eastern flank is not marketing. It shapes what we’re close to.
The questions we work on are not theoretical here. Airspace incursions, infrastructure under observation, and the practical problem of who is permitted to do what when an unidentified airframe crosses a boundary — these are current operational matters for our customers, not scenarios in a workshop.
Being an EU company matters for a second, drier reason: data stays in the Union, procurement runs under EU rules, and export control sits under one framework rather than three. For a government buyer, that removes a set of questions before the first conversation. For a critical infrastructure operator under NIS2 and CER, it removes a set of audit findings.
Vilnius or your office location. Quiet, documentary, daylight. Architecture or a working environment — not a skyline postcard, not a glass boardroom. 16:9, min. 2400px. If no suitable photograph exists, this figure can be removed entirely rather than filled with stock.
How we work
The question before the product
A large share of the enquiries we receive name a solution rather than a problem. We push back on that as a matter of course — not to be difficult, but because a system bought against an unexamined threat becomes an operating cost with an alert nobody answers. Our advisory work is contracted and paid separately from supply for exactly this reason. See Advisory.
Capability, not catalogue
We describe what a system does at your site, under your conditions, against your threat. We don’t publish specifications, and we don’t quote detection ranges without stating the conditions they were measured under — because a range without conditions is a number without meaning.
The handover is the product
Sensors are the easy part. What separates a system that works from one that gets muted is the path from „detected“ to „someone decided“ — who is told, with what authority, within what window. We write that chain before anything is installed, and we test it.
A human decides on effect
We build systems that sort, classify and recommend. We don’t build systems that decide to engage on their own. That is a design commitment, not a configuration option.
Compliance is upstream
Export control, data protection and the mandate question are settled before a project starts, not discovered during it. It’s slower at the beginning and considerably faster everywhere after. See Compliance.
The team
We don’t publish a team page with names and photographs. In this field, the people working on a protection concept for a named asset are not information that belongs on a public website — for their sake and for our customers‘.
What we can describe is the mix. The work needs four kinds of competence, and a project that’s missing one of them tends to fail in a predictable way:
| Competence | What it covers | Failure mode without it |
|---|---|---|
| Sensing and RF | Detection physics, interference environments, sensor fusion, calibration under real conditions. | A system that works on the test range and nowhere else. |
| Operations | Control rooms, escalation chains, stewarding, incident command. How an alert actually travels. | Detection that reaches a screen nobody is authorised to act on. |
| Regulatory | Mandate mapping, NIS2 and CER, aviation law, export control, data protection. | A capability that’s unlawful to use at the moment it’s needed. |
| Adversary | What is actually being flown, how it’s being modified, what stopped working last month. | A defence tuned to the threat of two years ago. |
The fourth is the one that can’t be hired into a European office and left there. It comes from our development partnership, and it’s the reason that partnership is structural rather than commercial. See Partners.
For a named point of contact on a specific project, ask. We introduce the people who’d do the work before a contract exists, under NDA where needed. We just don’t do it on a public page.
What we don’t do
A short list, because knowing where a supplier stops is more useful than another paragraph about what they claim to cover.
- We don’t bid on procurements we’ve advised on. Doing both would make the advice worthless.
- We don’t give legal advice. We map technical reality to regulatory requirement and work alongside your counsel. We’re not a law firm and won’t act like one.
- We don’t supply to sanctioned destinations. Not as a matter of policy preference — as a matter of law we take seriously. Enquiries are screened before they’re answered.
- We don’t publish effector specifications. Not on the website, not in a brochure, not in a first email.
- We don’t sell hardware as the answer to an unexamined question. Sometimes the honest recommendation is a concept and an exercise, and we’d rather say so than invoice for a system that gets switched off.