Which platforms and architectures are supported?

Ayonix does not publish a platform matrix, because a matrix is a per-version claim that goes stale and an OEM would discover that late. Target hardware, operating system and architecture are confirmed against your actual device at the first technical conversation, before you commit engineering time.

How is an OEM licence priced?

The engine is licensed monthly or as a one-time licence, and for embedded products the variables are how the count is taken — per unit shipped, per deployment, per developer — and what renewal looks like for units already in the field. No royalty schedule is published; terms are agreed per partnership and depend on volume and territory.

Can the product work with no network at all?

Yes. Matching can run entirely on the device or on a local appliance, with no call to an Ayonix service and no outbound connection required. That is the normal arrangement for gates, kiosks and terminals, and it is what makes the data residency answer short.

Can we white-label it?

Ayonix is not visible to your end customer unless you choose to name it. The interface, the branding and the customer relationship are yours; what you are licensing is the engine underneath them.

What accuracy can we put in our datasheet?

None from Ayonix. Recognition performance moves with the camera, the optics, the lighting, the matching threshold and the population, so a figure measured in one product cannot be reproduced in yours. Measure it inside your own envelope during evaluation, and publish that with its conditions if you publish anything.

Is Ayonix NIST certified?

No, and no vendor is. NIST runs evaluations and publishes reports on how submitted algorithms performed; it does not certify, approve or endorse vendors, and it maintains no approved-vendor list. Ayonix has participated in NIST face recognition evaluations, which means algorithms were measured — a certification claim would describe something that does not exist.

Do we get updates, and what do they break?

Update cadence and the compatibility commitments around it are part of the agreement rather than something to discover afterwards. The question worth asking explicitly is what happens to templates already enrolled in the field when the engine is updated, because that is the answer that decides whether an update is a download or a migration.

Face recognition SDK for OEM and embedded products

An SDK licence embeds Ayonix face recognition inside a product you own. You keep the interface, the customer and the brand; Ayonix supplies detection, template extraction and comparison, and the deployment stays on hardware you specify rather than on a service anyone calls out to.

By Jan Mocary, Chief Technology Officer, Ayonix AI

Last updated: September 19, 2026

How is an SDK licence different from deploying the product?

A deployment puts Ayonix software into an organisation that uses it. An SDK licence puts Ayonix inside something you sell. Those are different commercial relationships and they have different consequences.

	Deployment	SDK / OEM
Who holds the end customer	Ayonix or an integrator partner	You. Ayonix is not visible unless you name it
Who owns the interface	The Ayonix product	You. The UX is yours to design
Where it runs	Customer infrastructure, chosen at deployment	Hardware you specify, in a product you ship
What Ayonix supplies	A working system	Detection, template extraction and comparison, to build around

Two ways to take the same engine

What do you actually integrate against?

Face recognition breaks into four operations, and an SDK integration is a decision about which of them you take and which you build yourself.

Detection: find the faces in a frame, and decide which are usable enough to proceed with.
Template extraction: turn a usable face into a compact numeric representation. This is the part that is not reversible into a photograph.
Comparison: score one template against another, or against a set, and return the result with the score rather than only a verdict.
Storage and enrolment: hold the templates and manage their lifecycle. This is frequently the part an OEM keeps, because it belongs in your own data model.

The last one is worth deciding early. An OEM that keeps enrolment keeps control of its own schema, its deletion story and its customers' data residency answers. An OEM that hands enrolment over gains speed and loses some of that. Neither is wrong; drifting into one without choosing is.

Where does the compute sit in an embedded product?

This is the constraint that shapes everything else, because in an embedded product it is bounded by physics rather than by budget. Three arrangements, and the right one is usually decided by what the device has to do when it is offline.

Arrangement	Suits	The constraint
On the device itself	Gates, kiosks, terminals — anything that must work with no network	Thermal and power budget, and how many identities the device can hold
On a local appliance beside the devices	Several devices at one site sharing one directory	Something has to survive the link between device and appliance dropping
In your own backend	Products where the client is thin and connectivity is a given	Latency, and the fact that images now travel — which changes the privacy answer

Where the matching runs in a shipped product

ATLAS BOX, the edge applianceWhere an OEM would rather not design its own compute module for the middle case.

What shape is the licence?

Ayonix licenses the engine monthly or as a one-time licence. For an embedded product the variables that matter are how the count is taken — per device shipped, per developer, per site — and what happens at renewal for units already in the field.

Whether the count is per unit shipped, per deployment or per developer seat.
What a unit already in a customer's hands costs in year two.
Whether the licence travels with the device when your customer resells it.
What happens to shipped units if the agreement ends — the question your own customers will eventually ask you.

Ayonix does not publish a price list or a royalty schedule for OEM licensing, and this page will not print one. The terms depend on volume, territory and what each side commits to, and they are agreed per partnership. If a number is needed before you invest engineering time, say so at the first contact and you will get one.

What should an evaluation establish?

Not whether face recognition works. It does. An OEM evaluation exists to find out whether it works inside the specific envelope your product ships in, which is a narrower and much more useful question.

Run on the target hardware, not on a workstation. A result from a development machine tells you almost nothing about a fanless enclosure.
Run at the concurrency the product will see, including the worst minute rather than the average one.
Establish the identity count the device must hold, and test at that size rather than at a convenient one.
Decide one-to-one or one-to-many early: they have different cost curves as the gallery grows, and retrofitting the other later is a redesign.
Test the liveness requirement explicitly if the product will face an adversary, on the real optics rather than on a webcam.

How to run a face recognition pilotWhat to measure, on whose data, and how to tell a real result from a demonstration.
Accuracy, thresholds and livenessWhy one accuracy figure cannot describe a biometric system, and what to ask for instead.

What does Ayonix not supply?

Worth stating plainly, because an integration plan built on an assumption here is a plan with a hole in it.

Identity document authenticity checking. Face matching answers whether a person matches a photograph; whether the document is genuine is a different discipline.
The enrolment experience inside your product. The capture flow, the consent wording and the retry behaviour are yours, and they affect results more than most engine parameters do.
A published platform compatibility matrix. Target hardware is confirmed for your actual device rather than read off a grid that goes stale.
Accuracy figures you can quote to your customers. There are none, for the reason set out in the accuracy page.

Frequently asked questions

Which platforms and architectures are supported?: Ayonix does not publish a platform matrix, because a matrix is a per-version claim that goes stale and an OEM would discover that late. Target hardware, operating system and architecture are confirmed against your actual device at the first technical conversation, before you commit engineering time.
How is an OEM licence priced?: The engine is licensed monthly or as a one-time licence, and for embedded products the variables are how the count is taken — per unit shipped, per deployment, per developer — and what renewal looks like for units already in the field. No royalty schedule is published; terms are agreed per partnership and depend on volume and territory.
Can the product work with no network at all?: Yes. Matching can run entirely on the device or on a local appliance, with no call to an Ayonix service and no outbound connection required. That is the normal arrangement for gates, kiosks and terminals, and it is what makes the data residency answer short.
Can we white-label it?: Ayonix is not visible to your end customer unless you choose to name it. The interface, the branding and the customer relationship are yours; what you are licensing is the engine underneath them.
What accuracy can we put in our datasheet?: None from Ayonix. Recognition performance moves with the camera, the optics, the lighting, the matching threshold and the population, so a figure measured in one product cannot be reproduced in yours. Measure it inside your own envelope during evaluation, and publish that with its conditions if you publish anything.
Is Ayonix NIST certified?: No, and no vendor is. NIST runs evaluations and publishes reports on how submitted algorithms performed; it does not certify, approve or endorse vendors, and it maintains no approved-vendor list. Ayonix has participated in NIST face recognition evaluations, which means algorithms were measured — a certification claim would describe something that does not exist.
Do we get updates, and what do they break?: Update cadence and the compatibility commitments around it are part of the agreement rather than something to discover afterwards. The question worth asking explicitly is what happens to templates already enrolled in the field when the engine is updated, because that is the answer that decides whether an update is a download or a migration.