When should your company become a CNA rather than requesting CVE IDs through a root CNA?

## What CNA status actually is A CVE Numbering Authority is an organisation authorised by the CVE Program to assign CVE identifiers within an agreed scope, and to publish the records for what it assigns. CNAs are organised in a hierarchy: each is onboarded by and reports to a root, and the program keeps an assigner of last resort for vulnerabilities that fall in nobody's scope. Most vendor CNAs have a scope of 'vulnerabilities in our own products'. It is not a certification, a security rating, or a badge. It is an operational role with commitments attached. ## The case for taking it on **Timing.** You assign when you are ready to publish, not when another organisation's queue clears. Where an identifier, an advisory and a patch must land in the same hour - which is what coordinated release actually requires - depending on an external assigner introduces a step you do not control. **Ownership of the record.** You write the description, the affected products and the references, and you can update them when the range turns out to be wrong. Records assigned elsewhere describe your product in someone else's words, and correcting them is a request rather than an edit. **Scope clarity.** Once your products are inside your declared scope, researchers know where to send reports, and the ecosystem stops getting two entries for one flaw because two parties each asked a different assigner. **Signal.** For enterprise buyers and regulators, a vendor that assigns and publishes on its own products reads as one that has a real product security function. That is a side effect, not a reason. ## The case against Every benefit above assumes a function that exists on the day a report arrives. CNA status commits you to a public disclosure policy, a public location where your advisories appear, an intake that answers, and adherence to the program's rules on what gets assigned and when records are published. Those are answerable obligations - a researcher who cannot get a response from a CNA can escalate to its root. So the honest questions are: how many advisories will we publish a year? Who is on call for intake in August? Who arbitrates when engineering says a report is 'not a vulnerability, it is a hardening suggestion'? Do we have anywhere to publish that is not a marketing blog? If the answers are thin, the low-cost path is right: keep a disclosure policy, keep an intake address, and request identifiers through your root or the last-resort assigner when you actually need one. Nobody downstream cares who assigned the identifier; they care that the advisory is accurate and on time. ## The scope question that actually gets argued The interesting case is not your own code. It is the third-party component you bundle, and - worse - rename. Suppose you ship a product that embeds an upstream library, statically linked and shipped under your own product name, and a flaw is found in that library. Who assigns? The general principle is that assignment follows the scope covering the vulnerable product - so the flaw in the upstream library belongs to the upstream's CNA or, failing that, to a root. What you should not do is mint a second identifier for the same flaw because it also happens to be in your product. Duplicates split the ecosystem's view: half the consumers act on one, half on the other, one eventually gets rejected as a duplicate, and everybody who matched on the loser now has a stale entry. But there is a real problem underneath the etiquette. Your consumers' tooling resolves *your* product's coordinates, not the upstream library's. If you renamed or vendored the component, an upstream identifier alone will never match anything in their inventory, and they will never learn they are exposed. The resolution is one advisory under your identity, listing your affected product versions and your fixed versions, carrying the upstream identifier as an alias rather than as a new assignment. One flaw, one identifier, two documents describing different products' exposure to it. When the upstream is unresponsive, unmaintained, or disputes the finding, this stops being clean, and that is what a root is for: it arbitrates scope disagreements between assigners. Escalating is normal and it is faster than a public argument. ## How to decide Write down the volume, the portfolio, the contractual commitments you have already signed about disclosure timing, and who would staff it. If becoming a CNA would formalise something you already do, do it - the marginal cost is small and the control is worth having. If it would create a function that does not yet exist, build the function first: a disclosure policy, an intake, an advisory publication location and a habit of writing accurate ranges. Those deliver most of the downstream value on their own, and they are the prerequisites you would have to build anyway.