EdgeNFC
EdgeNFC
Buyer's guide
We sell one of these platforms, so read this the way you should read any vendor's guide: sceptically. What we can offer instead of neutrality is a framework you can point back at us. Every criterion below is written as a question to ask every vendor you talk to, in the same words, and several of them have answers we would rather you did not hear. Those are left in.
One fork decides most of it. Does the tag emit the same bytes every time it is read? If it does, whoever captures one read holds everything that tag will ever say, and their copy is a second original. If it does not — because the chip holds a secret key and signs a counter that only moves forward — a captured read is spent the moment it is reused. Everything else here is a refinement of that question.
No company is named anywhere on this page, including in the tables. Naming one means committing to keep every claim about it accurate forever, and we would rather spend that effort on the product than on a quarterly re-check of somebody else's price list.
Criterion 1
This is the architectural fork. What a system can and cannot prove follows from it, and no amount of software on the server moves a deployment from one side to the other.
A serial, an identifier, a payload written once — if the tag returns the same bytes on every read, reading it once is the same as owning it. The copy verifies, because verifying means "is this string one of mine", and the copy contains the string.
Not a forgery and not an approximation: an identical artefact. No reader anywhere can tell the two apart, because there is nothing to tell apart. Length and randomness make a string harder to guess, never harder to copy.
For a tag to say something new each time, it must hold a key nothing can read back out of it and use that key to compute over something that changes. On NTAG 424 DNA that is an AES key installed at provisioning, an AES-CMAC over the mirrored data, and an internal read counter that only moves forward.
A payload can be encrypted and still be static: if the ciphertext is written once and returned unchanged, copying the ciphertext copies the credential. Ask what differs between two consecutive reads of the same tag, and what the server checks that difference against.
Analytics that flag one identifier appearing in two countries an hour apart are worth having, and every serious platform should offer them. They are statistical, after the fact, and silent when the counterfeit is scanned before the original. They suggest something went wrong; they cannot tell the person holding the object that this one is real.
A system built on static identifiers can add dashboards, analytics and serialisation. It cannot add per-tap proof without different silicon inside products you have already shipped. If you might ever need the stronger claim, the decision belongs at purchase.
Ask: what changes between two consecutive reads of the same tag, and what does the server check it against?
Criterion 2
Every one of these systems has a secret at the bottom of it. The question is not whether it is protected — everyone says it is — but who is left holding it on the worst day.
The platform generates and stores your master key. Easiest to operate: nothing to upload, nothing to back up, nothing to lose to a forgotten passphrase. It also means a breach of the vendor is a breach of your tags, and a vendor that shuts down takes your fleet's provable authenticity with it.
You generate the key; the platform stores it envelope-encrypted under a wrapping key held in a KMS or HSM. This is the common middle, and it is a real improvement. The plaintext still exists briefly in the vendor's memory at verification time — ask them to describe that moment precisely. A vendor who cannot describe it is not doing it.
You hold the master key and run the verifier. Nobody can breach out of a vendor what the vendor never had — and nobody can recover it for you either. A lost key with no backup is a fleet that can never be verified again. The strongest option, with the sharpest edge.
Ask this independently of the above. A single key shared across a fleet means one tag taken apart in a lab compromises all of them. A per-tag key derived one-way from a master — NXP's AN10922 diversification is the standard way — means a teardown yields exactly one tag and teaches an attacker nothing about the rest.
Write the answer down for each option: whose keys are they, where is the registry, and can anything already in the field still be verified. If the honest answer is "nothing works", that is a business risk rather than a technical one, and it still belongs in the decision.
Be wary when the only way to hold your own keys is the largest contract on the price list, and be equally wary of a platform that offers custody choices but cannot explain the operational difference between them. Ask what changes in your runbook, not in your invoice.
Ask: who can read my master key in plaintext, at what moment, and what is my recovery path if I hold it and lose it?
Criterion 3
Pricing is not only a cost line. A metered price is a signal to your own organisation about whether taps are a good thing, and people respond to signals.
If each verification costs, then every extra touchpoint and every enthusiastic customer is a line on a bill. Teams respond by tagging fewer items and promoting the tap less — the exact behaviour the system exists to encourage. Model the year you succeed, not the month you start.
A pilot of a few hundred tags scanned a handful of times each may well cost less on a metered plan than on any flat subscription, ours included. If you are testing an idea rather than running a programme, the arithmetic can favour metering, and no amount of architecture talk should override arithmetic.
Nobody charges nothing. If verifications are unlimited, find what is counted instead: active tags, campaigns, seats, custom domains, API calls. That is a legitimate model — but locate the number before you sign, and check how it behaves as the programme grows.
Some vendors will license the verification engine outright for you to run. That turns a subscription into a capital item and removes the vendor from the hot path entirely. It also transfers uptime, patching and state management onto your team, which is a real cost even though it is not an invoice.
Ask what literally happens when you cross a limit. Are taps rejected, is verification degraded, are you invoiced, are you emailed? A platform that fails a customer's verification at the counter over a billing threshold has made a product decision, and you should find out which one before your customers do.
A cheap first year that assumes you will still be there in year five is a different offer from a price that stands on its own. Ask what renewal looks like, what happens to your data if you stop paying, and whether tags keep verifying during a lapse.
Ask: what is metered, what does this cost at ten times my volume, and what does a customer see the moment I cross a limit?
Criterion 4
Software you can switch. Tags you have shipped are physical objects with somebody's keys inside them, and that is where the real cost of leaving sits.
If you do, tags in the field can be re-provisioned or verified by anything that knows the key, including code you write yourself. If you do not, the only party who can prove your tags are yours is the party you are trying to leave.
Tag identifiers, counters, provisioning state, verification history. Ask for the export format before you sign, not after. An export that omits counters leaves you unable to reject replays on day one of a migration, which is the day you can least afford it.
Re-keying is a physical operation: an authenticated session against every tag, one at a time. For stock in a warehouse that is a task. For tags on products already sold it is not possible at all, so count how many are out there when you assess the cost of switching.
The tap URL is written into the tag. If it points at a domain the vendor owns, moving platforms means every tag in existence points somewhere you no longer control. A custom domain is not a vanity feature here; it is the difference between a migration and a write-off.
SDM/SUN is published by NXP: the URL parameters, the key derivation and the MAC construction are all specified. A deployment built on the documented scheme can in principle be verified by a different implementation of the same scheme. A proprietary payload cannot be, by construction.
Before you commit a production run, provision a handful of tags, export everything the platform will give you, and see whether you could verify those tags without the platform's help. Whatever you learn is what leaving will feel like, multiplied.
Ask: if I leave, what can I still do with the tags already on products — and can I answer that without you?
Criterion 5
Per-tap proof is a property of the silicon. It cannot be added later in software, and most tags do not need it.
A chip that can hold AES keys which are never readable back out, compute an AES-CMAC over the data it mirrors into the URL, and increment an internal read counter on every read. NTAG 424 DNA does all three. A chip with no AES engine and no key store cannot, whatever the platform around it does.
A common Type 2 tag can mirror its UID, mirror a one-way read counter, lock its memory against rewriting and gate writes behind a password. Those are real protections that catch real problems: someone who copied your URL and shared it, or someone trying to re-point your tag at their own site.
Nothing on those chips authenticates the values they mirror. Anything that can emit an NDEF record of its choosing can emit whatever counter it likes. That defeats a copied link. It does not defeat a copied tag, and no server-side cleverness closes the gap.
Shelf talkers, Wi-Fi handoff, review prompts, conference badges, care instructions. Nobody forges those, and cryptography there is money spent on nothing. We publish a whole page arguing for the cheaper chip: NTAG 424 DNA vs 213 and 215.
A field of non-SDM tags cannot be converted by re-provisioning them; the capability is not in the silicon. If a batch might ever need to prove itself, buy the capable chip for that batch even if you switch the feature on a year later.
Chip families are easy to blur in a product description. Insist the exact part number appears in the specification, and be suspicious of any listing that will not name the silicon. Mixed inventory is a painful thing to discover during provisioning.
Ask: which exact part number are you provisioning, and what breaks if I bring a different one?
Criterion 6
Two separate questions hide inside "where is it verified": whose machine runs the check, and whose machine holds the state that makes replay rejection possible.
The tap goes to the vendor, who checks it and answers. Simplest to run — and the vendor sees every verification: timing, volume, and depending on the URL scheme, which tag. Ask what is logged and for how long, and whether the tag identifier appears in the link at all; the encrypted variant of the SUN scheme keeps it out.
You run the verification engine on your own infrastructure. Nothing about your fleet leaves it and you control the failure mode. You also own uptime, deployment, patching and the counter state — all of which the hosted option was quietly doing for you.
If checks must work with no network — a warehouse, a border post, a secure facility — the verifying code has to run locally and you must decide what "replay" means without shared state. This requirement rules platforms out more often than any other, so raise it in the first conversation rather than the last.
Rejecting a replayed tap means remembering the highest counter seen for that tag. A hosted system keeps that state for you. Self-hosted and offline deployments do not, unless you build it — and without it a captured URL replays successfully even though the cryptography is flawless.
If a vendor offers hosted and self-hosted, ask whether they are the same code. Two implementations of one scheme means two sets of bugs and a real chance that a tag verified in one place is rejected in the other.
A verdict page is a web page somebody has to host, brand and keep up. Ask whether it is yours or theirs, whether an authentic tap can be routed to your own destination, and what a failed tap shows — because that page is the product for everyone except you.
Ask: can this verify with no network, and who is responsible for remembering counters?
Criterion 7
A demo is one tag and one tap. A programme is tens of thousands of tags, a factory, a key rotation and eventually a recall.
Every tag needs an authenticated session before it is useful. Ask how that happens at your volume — a phone tap per tag, a desk encoder, an inline encoder on the line — how long one tag takes, and whether the pass can run unattended.
Can tags be provisioned in batches, and is there a read-back check proving each one landed? A half-provisioned tag is a brick, and discovering that at the point of sale is the most expensive place to discover it.
Ask what rotation actually costs. If the key lives in the tag, rotating usually means touching every tag again. Ask whether the verifier accepts the old and the new key during a migration window, and how long that window may be.
A tag is lost, stolen, or attached to a recalled product. How quickly does a tap of that tag start failing, everywhere? Ask for a propagation time as a number, and be wary of any vendor who has not thought about it — including us.
Two more that only surface after go-live. First, who provisions: a master key that has to reach a contract manufacturer is a key that has left your building, so ask whether provisioning can happen without the master key ever being present on the device doing it. Second, what a failed tap says: "not verified" has to be phrased for a confused shopper, not an engineer, and someone has to write that page before your first counterfeit shows up rather than after.
Ask: walk me through provisioning fifty thousand tags, rotating a key, and revoking a single tag — with times.
Criterion 8
These are not gotchas. They are the honest boundaries of the technology, and a vendor who denies one is telling you something useful about the rest of their answers.
The cryptography establishes that a particular chip was present and that this read was not a replay. Whether that says anything about the item depends entirely on how the tag is attached. A tag peeled off a genuine item and stuck to a fake proves only that the tag is genuine. No vendor's mathematics fixes adhesive.
Some phones and operating-system versions do not reliably hand the link off to a browser when a tag is tapped from the lock screen or home screen. It is platform behaviour and it varies by device. Any vendor promising a universal tap experience is overselling; ask what their fallback is.
Has the verification implementation been reviewed by anyone outside the company? Ask for the report, or for a plain "not yet". Both are usable answers when you are sizing risk. A vague one is not, and it tells you how the next hard question will go.
The key derivation and MAC construction have published test vectors. Ask whether the implementation reproduces them and whether you can check that yourself. Ours are checkable in your browser with the free AN10922 calculator and the SUN decoder — and you are welcome to point both at somebody else's output.
There is a difference between "the code implements the encrypted mode correctly against the specification" and "we have run that mode against production silicon at scale". Ask which is true of each mode a vendor offers, and keep the answers separate in your notes.
Any claim about counterfeit reduction, scan volumes or detection rates should arrive with how it was measured, over what period, on whose deployment. If it does not, treat it as a slogan. We publish no such numbers, which is itself a data point about us.
Ask: what is the least flattering true thing about your platform? A vendor with no answer has not gone looking.
Take this with you
One question per criterion. Ask every vendor the same words, us included, and compare the answers rather than the brochures.
| Criterion | Ask exactly this | Why the answer matters |
|---|---|---|
| 1 · Static vs dynamic | "What changes between two consecutive reads of the same tag, and what does the server check it against?" | If nothing changes, one captured read is a working copy forever. |
| 2 · Key custody | "Who can read my master key in plaintext, and at exactly what moment?" | Decides what a breach of the vendor costs you, and what a wind-down costs you. |
| 3 · Pricing model | "What is metered, and what does this deployment cost at ten times the volume?" | A metered tap is a standing reason for your own team not to deploy. |
| 4 · Exit | "If I leave, what can I still do with the tags already on products?" | Shipped tags are the switching cost, and it grows with every batch. |
| 5 · Chip | "Which exact part number, and what breaks if I bring a different one?" | Per-tap proof is silicon. It cannot be added after the run is made. |
| 6 · Verification location | "Can this verify with no network, and who remembers the counters?" | Replay rejection is state, and somebody has to be holding it. |
| 7 · Operations | "Talk me through fifty thousand tags, one key rotation and one revocation." | This is where programmes actually fail, long after the demo. |
| 8 · Limits | "What is the least flattering true thing about your platform?" | A vendor with no answer has not looked, or will not say. |
There is deliberately no scorecard here. A scoring system built by a vendor tends to weight the rows that vendor wins, and you would be right not to trust ours.
Credit where it is due
The most useful outcome of this guide may be that you buy nothing. These are the cases where a platform — ours or anyone else's — is the wrong shape for the problem.
Threat models need an attacker with an incentive. Low unit value, no resale market, no warranty exposure, no access being granted: cryptography is decoration, and the budget is better spent on the thing being tagged.
Any camera, any distance, through glass, on paper, on a screen, for free. If your interaction never involves someone touching the object, no NFC platform helps. We wrote the honest version of that comparison, concessions first: NFC vs QR codes.
If the real problem is grey-market diversion, warranty fraud or supply-chain visibility, unique identifiers plus good reporting may solve it completely — and a printed serial carries an identifier as well as a chip does.
The scheme is documented. The key derivation and the MAC construction are published algorithms with published test vectors, the URL parameters are specified, and verification is a modest amount of code against a well-tested crypto library. With the engineers and the time, a platform buys you speed, not capability — and our free key calculator and URL decoder exist partly so you can check your own implementation. We are aware that helps you not need us.
Tamper-evident packaging, destructive seals, and construction that makes swapping a tag obvious can matter more than the tag, because the attachment is the weak joint in every one of these systems. Budget for it before you budget for software.
If the product design is not settled, tagging is premature. A tag has to live somewhere on a physical object, and where it lives constrains the tag far more than the tag constrains the product.
Our own answers
Same eight criteria, same order, with the rows we lose left in. Put whatever you get from anybody else beside it.
| Criterion | What EdgeNFC actually does |
|---|---|
| 1 · Static vs dynamic | Dynamic. The tag holds an AES key it never reveals, signs each read with an AES-CMAC, and mirrors a read counter that only moves forward. A forged link fails the MAC; a replayed one fails the counter. |
| 2 · Key custody | Two options. Hosted: your master key is stored envelope-encrypted and exists in plaintext only transiently, at verification. Self-hosted: the master key is shown once at creation and never persisted by us — including on the day you lose it. |
| 3 · Pricing model | Unlimited verifications on every tier, including the free one. The meter is the count of active tags, never a tap. For a small pilot we are more expensive than metered pricing, and that is the honest comparison. |
| 4 · Exit | Self-hosted holds its own keys, and the scheme is NXP's documented one rather than ours, so tags are not tied to our implementation. Hosted does not hand back plaintext master keys — a real limit on exit, and we will not dress it up. |
| 5 · Chip | NTAG 424 DNA only, because nothing else carries SDM/SUN. If your fleet is on another chip, we are not the answer and re-tagging is rarely worth it. |
| 6 · Verification location | Hosted verification runs at the edge, near your customer. The identical Rust/WASM core is licensed to run on your own infrastructure — one-time, perpetual, $749. In self-hosted and offline use you own the counter state and therefore the replay policy. |
| 7 · Operations | Provisioning is an authenticated pass per tag from an Android app, with a read-back check before a tag is marked done. There is no inline production-line encoder; at very large volumes that is a genuine constraint. |
| 8 · Limits | No independent audit yet. Key rotation requires re-provisioning the tags. We publish no revocation propagation target. We do not sell tags. |
Every claim in this table traces to a published design document rather than to a benchmark. There are no performance numbers on this page because we have not measured any of them well enough to publish.
Straight answer
Applying our own criteria to ourselves gets these results. If you recognise your programme here, we would rather say so on our own page than in a sales call.
We verify one scheme, on one chip family. If your form factor, your supplier or the tags you have already shipped are built on something else, nothing we do applies, and re-tagging an installed base is almost never worth the money.
Provisioning is an authenticated pass per tag from a phone. That is comfortable for thousands and painful for hundreds of thousands. If tags must be encoded inline as part of manufacturing, that constraint should decide your shortlist before anything else on this page does.
We do not publish a propagation-time target for revoking a tag. If your compliance regime needs that number written into an agreement, we cannot give you one today, and you should ask vendors who can rather than take our word that it is fast.
There has been no independent security audit and we hold no security certification. If a signed third-party review is a gate in your process, that is a legitimate blocker, and no amount of design description substitutes for the document you actually need.
Millions of low-value items where fractions of a cent decide the programme. The capable chip costs more than the simple one and always will. If the tag is a meaningful share of the item's value, buy the cheaper chip and spend the difference on something that moves the number.
NFC requires contact by design. Scanning across a counter, through a window or off a shelf label is a camera's job, and no chip changes that. Print a code and put the effort into what the code opens.
A master key to protect, per-tag keys derived from it, a provisioning pass over NFC, and a custody decision. It is not enormous — the key management playbook walks the whole thing — but it is real work that a printed code never asks of you.
We are software. Tags come from a specialist supplier and you provision them yourself. If your procurement wants one purchase order and one throat to choke across the whole stack, we are the wrong shape for that and we will not pretend otherwise.
Straight answers
It proves the tag is genuine, present, and not replayed. Whether that transfers to the item depends on how the tag is attached — a tag that can be peeled off a real item and stuck on a fake one proves only that the tag is real. Design the attachment as carefully as the crypto.
Not always. Some Android phones and versions have a known platform quirk where tapping an NTAG 424 DNA tag doesn't reliably hand the link off to a browser from the home screen or lock screen. It's outside our control, and it varies by device. The reliable workaround is to open the EdgeNFC app and scan the tag from there — same read, same verdict. Ask every vendor on your list what their answer to this is, because it affects all of them.
No. EdgeNFC is software: we provision and verify tags, we don't sell them. You buy blank NTAG 424 DNA tags from a specialist supplier and provision them yourself — see where to buy tags. Any hardware figure in your model is therefore somebody else's price list, and we are not the right people to quote it.
Not yet. We have not commissioned a third-party audit or obtained any security certification, and we will say so here until that changes. What we can point at today is the design, standard primitives, and conformance against published NXP vectors.
No, and you should not treat it as neutral — we sell one of the things it describes. What we have done instead is write every criterion as a question you can ask us in the same words as everyone else, keep every company name off the page, and leave in the rows we lose. Take the question sheet. You do not have to take our answers.
Because a page that names a competitor has to stay right about them forever. That means legal review, a dated record behind every claim, an owner re-checking each quarter, and a published process for corrections — a permanent cost that buys a reader very little, since other people's pricing and features change without telling us. Naming nobody is the honest version of the same page.
FAQ
Does the tag emit the same bytes on every read? If it does, anyone who captures one read holds everything that tag will ever produce, and their copy is indistinguishable from the original. If it does not — because the chip holds a secret key and signs a counter that only moves forward — a captured read is worthless the second time it is used. Every other criterion is a refinement of that one.
Yes, for a small pilot. A few hundred tags scanned a handful of times each can genuinely cost less on a metered plan than on any flat subscription, ours included. The question to ask is what the same deployment costs at ten times the volume, because that is where metered pricing starts arguing against the thing you actually want, which is for people to tap.
Whoever can least afford to lose control of it and can actually operate it. A vendor-held key is one breach away from being someone else's; a customer-held key is one lost backup away from being nobody's. There is no answer that is right for everyone, so ask which custody options a vendor supports, and what happens to your tags under each if that vendor stops existing.
Ask three things before you buy: do you hold the master key, can you export the tag registry with its identifiers and counters, and can tags already in the field be re-provisioned by someone else. If all three answers are no, the tags you have shipped are the switching cost, and it grows with every batch.
Only if you need per-tap proof. A cheaper NFC chip has no key to sign with, so it can carry an identifier and a plain counter but cannot show that this particular tap happened just now. If the tag's job is to open a link, buy the cheap chip and spend the difference somewhere it matters.
Next
The demo runs the real verification core in your browser. Change a byte of the MAC, or replay a counter, and watch it refuse — no signup, nothing leaves the page.