Uniqcli

CMMC control families

CMMC Identification & Authentication (3.5 IA): 11 requirements and what sits behind them

Eleven requirements, and the one everybody argues about is 3.5.3. The credential, the enrollment process and the identity provider do the work. What we put behind them is the reader, the multifactor licensing that runs alongside it, the rollout work — and an honest answer about hardware tokens, which we cannot promise from stock.

Family
3.5 — Identification & Authentication
Requirements
11 of the 110 Level 2 requirements
Level 1
In scope — basic requirements from this family
Boundary
The capability behind the control — never a certification we hold
Overview

Prove who is asking, and prove it with more than a password

Identification and authentication carries eleven requirements: identify users, processes and devices (3.5.1), authenticate those identities as a prerequisite to access (3.5.2), and then the one that dominates every conversation — multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts (3.5.3), backed by replay-resistant mechanisms (3.5.4). The rest govern identifier reuse, password composition and lifetime, cryptographically protected storage and transmission of passwords (3.5.10) and obscured authentication feedback (3.5.11). 3.5.3 is the requirement most often misread, because "local" and "network" access are scoped differently for privileged and non-privileged accounts — which is why this family is worth reading closely rather than shopping quickly.

Levels

What each level asks of this family

Identification and authentication is one of the six families Level 1 touches. The basic requirements at that level are about identifying users, processes and devices acting on their behalf, and authenticating those identities before granting access — the FAR 52.204-21 baseline, not the full eleven.

Level 2 is where 3.5.3 and 3.5.4 arrive, along with the password and authenticator management requirements at 3.5.7 through 3.5.11. Read 3.5.3 precisely: it is multifactor for local and network access to privileged accounts, and for network access to non-privileged accounts. That is not the same as "MFA on everything", and it is not satisfied by a second password.

Level 3 layers enhanced requirements from NIST SP 800-172 onto a Final Level 2, assessed by DIBCAC.

What's quotable

What you can actually quote against this family

Each card names the requirement the line serves — hardware, software licensing or the integration work that puts either into service. Naming a control is not a coverage claim: the configuration, the procedure and the evidence stay inside your program, and no purchase — hardware, license or service — confers certification on its own. Naming a manufacturer describes the market, not a Uniqcli partnership or endorsement.

CAC and PIV readers (3.5.3)

Smart-card readers are the physical half of a credential-based second factor, and the shelf here is genuinely thin: across the hub, dozens of reader rows exist but only a handful are in stock at any moment. IOGEAR, Adesso, Belkin, Rocstor and Vertiv have stocked models; Panasonic, RF IDeas, Kensington and Zebra rows are priced but not stocked. Expect this to be a quote-and-source line with a real lead time, and plan the rollout around that rather than around a ship date we have not confirmed.

Readers built into the keyboard

Where desk space or a locked-down chassis rules out a separate reader, keyboards with an integrated smart-card slot are the usual answer — Adesso and Rocstor both appear, and IOGEAR has a CAC-reader keyboard. Availability is better here than on standalone readers, but the same rule applies: the quote states the stock position per line before you commit.

Hardware tokens are quote-and-source only

This is the honest part. Security keys and one-time-password tokens appear in our catalog in volume — Yubico and RSA both have large row counts — but not one of those rows is priced or in stock on the hub today. We will not promise FIDO2 key availability, and you should be skeptical of anyone who does without naming a lead time. Send the model and quantity and we will tell you what can actually be sourced and when.

A credentialed desk across two networks

Where the second factor has to travel with an operator working across separated networks, NIAP Peripheral Sharing Device secure KVM units with a CAC reader in the console are the ordinary route — several ATEN rows state PSD PP v4.0 and CAC support in the title, with Vertiv's Cybex line alongside. Availability varies by model and the quote confirms it.

Multifactor licensing alongside the reader

The software half of a second factor is a line item too. ESET's Secure Authentication subscriptions are priced in our licensing catalog and quoted per seat against your term. Software is sourced through authorized US distribution rather than held on a shelf, so availability language does not apply to it. We do not carry a privileged-access-management or single-sign-on product line — those names are not in our catalog, and we will say so rather than promise to find them. Naming a manufacturer describes the market, not a Uniqcli partnership or endorsement.

Getting the rollout onto the desks

A reader program stalls on logistics more often than on procurement. The same order can carry imaging and configuration of the endpoints the readers attach to, kitting and asset tagging per site, and phased release scheduling so each location receives a labeled kit rather than a bulk shipment. Scoped per order; the credential issuance and enrollment stay yours.

Limits

What stays yours to run

A reader is not a factor, and a subscription is not an identity program. The credential, the middleware, the identity provider, the enrollment process and the account model are what an assessor examines under 3.5.3 — the reader is the capability behind the control, and buying one changes nothing on its own. Password policy under 3.5.7 and 3.5.8, cryptographic protection of stored and transmitted passwords under 3.5.10, and obscured feedback under 3.5.11 are all configuration. The program stays yours to run — the policy, the decisions, the cadence and the evidence an assessor actually reads. What a supplier puts behind it is the tooling, the licensing and the integration work.

Where cryptography protects CUI, 3.13.11 asks for FIPS-validated modules — a fact about the module, evidenced by a CMVP listing. 3.5.3 itself does not say FIPS, so whether the authenticator falls inside that scope is a scoping call for your program and your assessor. Ask us for the CMVP certificate on any line where the module is the point and we confirm it on request before you commit.

We are not an assessor, a C3PAO or an RPO, and we hold no CMMC level. We quote against the SSP you already have — hardware, licensing and the integration work around them — not a generic bundle assembled around a level number.

Questions

MFA and authentication questions

Does CMMC require MFA on every account or only privileged ones?

3.5.3 requires multifactor authentication for local and network access to privileged accounts, and for network access to non-privileged accounts. Local access to a non-privileged account is not covered by that wording. Read it against your own architecture rather than against a vendor summary — the scoping of "local" and "network" is exactly where assessments go wrong.

Does CMMC MFA have to be FIPS-validated?

3.5.3 does not itself say FIPS. 3.13.11 requires FIPS-validated cryptography when cryptography is used to protect the confidentiality of CUI, so whether a given authenticator falls inside that scope depends on how it is used in your system. The product-level fact that matters is the CMVP listing, and we confirm certificates on request rather than printing them per line.

Do CAC or PIV readers satisfy the CMMC MFA requirement?

A reader on its own satisfies nothing. It is the peripheral that lets a credential you already issue participate in authentication — the credential, the middleware, the identity provider and the enrollment process do the work the requirement is about. We supply the equipment behind the control, never a certification we hold.

Is identification and authentication part of CMMC Level 1?

Yes. It is one of the six families Level 1 touches, alongside access control, media protection, physical protection, system and communications protection, and system and information integrity. The Level 1 set is 15 requirements drawn from FAR 52.204-21; the full eleven in this family arrive at Level 2.

Get a CMMC estimate — CMMC Identification & Authentication (3.5 IA)

Tell us where to reach you and a Uniqcli specialist follows up by email to scope what you need across hardware, software licensing and integration, then comes back with pricing and availability — quoted against the SSP you already have, not a generic bundle.

An estimate for the capability behind the control — never a certification we hold. No purchase — hardware, license or service — confers a CMMC level on its own; what you buy makes the controls implementable.

Do not submit classified information, CUI, restricted FCI, export-controlled technical data, protected health information, payment-card data, passwords, or private keys through this form. Contact your Uniqcli representative or [email protected] to request an approved channel.

CUI, FCI and secure submission notice

Ask AI about Uniqcli

CMMC Identification & Authentication (3.5 IA)

Talk to us about readers, licensing and the rollout

Send the model and quantity, or the rollout you are planning. A Uniqcli specialist replies with an estimate and an honest lead time covering the readers, any multifactor licensing alongside them and the staging work per site — readers are a thin shelf and hardware tokens are quote-and-source, so the answer will say what can actually be sourced rather than what looks good on a page.