Identity Entry and federal ICAM.

1The short version

Identity Entry checks who a person is, decides whether they may walk through a door, and screens their records. Those are three of the jobs the federal government groups under ICAM.

ICAM stands for Identity, Credential, and Access Management. The General Services Administration describes it as the tools, policies and systems an agency uses so the right person reaches the right resource, at the right time, for the right reason.^[1] FICAM is the federal government’s own version of that practice, with an architecture, a set of playbooks and a stack of policy behind it.^[2]

Identity Entry is a commercial service. It gives an agency, a prime contractor or a company four products that can be bought on their own or together: Identity Entry Verify, Identity Entry Access, Identity Entry 360 and Identity Entry Shield. All four share one record of the person, which this page calls the profile. The person controls who may use it.

This page walks through the FICAM model one part at a time and shows where each Identity Entry product is designed to fit. It also marks, just as plainly, where Identity Entry stops. It does not issue PIV cards. It holds no FedRAMP authorization. It has not been certified at any NIST assurance level. Those limits have their own chapter, and they apply to every claim made here.

2Identity verification, biometric entry and background screening

Most buyers arrive with one of three needs. Each one maps to a product, and all three meet in the same profile.

Identity verification: Identity Entry Verify

Identity verification answers one question: is this person who they say they are? Identity Entry Verify answers it in two sizes. The ID check costs $1 a person and runs three checks. It reads the front and back of a government ID, matches a live selfie to the photo on that ID, and confirms through random head movements that a real person is in front of the camera rather than a printed photo or a screen. The result is Pass, Caution or Fail, with the reasons attached.

Background costs $20 a person and runs all seven levels: ID, Face and Liveness, then Watchlist, Contact, Bank and Background. The person signs one authorization at the start, and Identity Entry checks the outside sources without asking them for anything more. Background is the $20 product’s name, and it is also the name of the seventh level, the public records search. The overlap is deliberate. Background is where identity verification turns into screening.

Biometric entry: Identity Entry Access

Biometric entry answers a different question: may this person walk in here, now? Identity Entry Access costs $2 for each person on an entry list, whether or not that person is ever scanned. A person verifies once, or reuses the profile they already have, and agrees to face-based entry when they enroll. At the door, a phone or tablet scans their face. A match opens the way only for someone who holds a pass for that place. Staff can admit a person by hand, and the reason is recorded.

Background screening: Background and Identity Entry 360

Background screening answers the question a contracting officer asks before trusting someone with a site, a system or a payment: what does the record show? Background covers the seven levels. Identity Entry 360 costs $100 a person and adds five records to them: driving record, education, tax filing, security clearance and criminal records, for 12 checks in all. It is Identity Entry’s most comprehensive background and identity check, and the product to look at for government level vetting.

A record source that is not connected yet shows as not connected and never counts as a pass. Chapter 7 lists which sources answer today and which wait on a government partner.

3What ICAM is, in plain words

Three questions sit under every badge, login and locked door. Who is this? What did we give them to prove it? Where may they go?

Picture a contractor’s first morning on a federal job. Before the badge office prints anything, someone at the agency has to be satisfied that the contractor is a real person with the name on the paperwork. Then the contractor needs something to carry: a card, a key, a login. Then every door and every system has to decide, again and again, whether that thing is enough to let them in.

Those three steps are the three practice areas in GSA’s FICAM Architecture.^[1] The architecture gives each a one-line definition, quoted here in full because the wording matters:

• Identity management is how an agency collects, verifies, and manages attributes to establish and maintain enterprise identities for employees and contractors.
• Credential management is how an agency issues, manages, and revokes credentials bound to enterprise identities.
• Access management is how an agency authenticates enterprise identities and authorizes appropriate access to protected services.

Two supporting elements sit beside them. Federation lets an agency accept identities, attributes and credentials that someone else manages. Governance is the set of practices and systems that guide the other four and check their results.^[1]

Identity is a set of attributes

The architecture treats an identity as a bundle of attributes that changes over time. A person’s identity inside their agency’s HR system differs from their identity at their bank. Their identity as a contractor differs from their identity as a reservist. The person stays the same; the attributes around them change when they are promoted, change their name, finish training or retire.^[1]

GSA sorts those attributes into three kinds. Core attributes are things like name and address of record. Contact attributes are a work location, phone number and email. Authorization attributes include clearance, training and job codes.^[1] That last group matters for this page, because a security clearance is listed there as an attribute an agency manages, and Identity Entry 360 asks about one.

A credential binds something you carry to that identity

The architecture defines a credential as a data structure that authoritatively binds an authenticator to an identity. The authenticator can be something you know, like a PIN; something you have, like a private key on a smart card; or something you are, like a fingerprint. The PIV card and the Common Access Card are the federal examples: each carries a photo and cryptographic key pairs, and each is issued by the agency.^[1] Credentials can expire. Identities continue, and the agency issues a new credential when the old one runs out.

Access is two decisions, made in order

Authentication asks whether the credential is genuine and belongs to the person presenting it. Authorization asks whether that person may do this particular thing. GSA describes access models on a scale of granularity: access control lists, then role-based access, then attribute-based access, then risk-adaptive access, and notes that most agencies start with roles and move toward the finer models over time.^[1]

The architecture gives three example rules, from simple to strict. Grant access to anyone on this list. Grant access to any employee or contractor with an authenticated PIV card. Grant access to anyone who is a federal employee at GS-12 or higher, cleared Top Secret, trained in first aid and certified as a project manager.^[1] Identity Entry Access works at the first of those levels, a list of people who hold a pass for a place, with rules about zones, days and re-entry on top.

Who the federal architecture covers

The FICAM Architecture is written for enterprise identity: government employees, contractors and authorized partners. GSA states that citizen interactions with the government, consumer ICAM, are outside this version of the architecture.^[1] Contractor vetting therefore sits squarely inside it, which is why this page uses the contractor as its running example.

4FICAM: the federal program

Twenty-one years of directives, standards and memoranda shape how an agency handles identity today. Five of them matter most for contractor vetting.

HSPD-12 and FIPS 201: the common credential

In August 2004, Homeland Security Presidential Directive 12 called for a common identification standard for federal employees and contractors.^[3] NIST answered with FIPS 201, the standard for Personal Identity Verification. Its current edition, FIPS 201-3, was published in January 2022. It sets the requirements for identity proofing before a PIV card is issued, for the infrastructure that lets agencies trust each other’s cards, and for accrediting the organizations that issue them.^[4]

The PIV card is how an employee or contractor proves who they are at a federal door or a federal computer. GSA’s PIV 101 course walks through the life of a card from sponsorship to issuance and use.^[5] The card is issued by a government agency, or by an issuer acting for one, under that standard. No commercial service can stand in for it, and Identity Entry does not try.

M-19-17: manage identities, not just cards

In May 2019, the Office of Management and Budget issued M-19-17, Enabling Mission Delivery through Improved Identity, Credential, and Access Management.^[6] It replaced a generation of earlier identity memos, including M-04-04 and M-11-11. It asks each agency to set up an integrated, agency-wide ICAM office, team or governance structure. It points agencies to NIST’s Digital Identity Guidelines for identity proofing and authentication. It keeps HSPD-12 and the PIV card at the center of the federal workforce credential while directing agencies to focus on the life of the identity rather than only the life of the card. It also tasks GSA with a roadmap of shared solutions agencies can use.

That shift from credential to identity is the reason a service like Identity Entry has a place in the conversation at all. An agency that manages the whole life of an identity cares about the steps before a card exists and the people who never receive one.

The FICAM Architecture and the playbooks

GSA publishes the FICAM Architecture as a framework for agency ICAM programs and roadmaps. Version 3.0 arrived in November 2019, and the current version, 3.3, is dated June 2023.^[1] Around it sits a library of playbooks, each a practical guide to one part of the work. The current list includes the Cloud Identity Playbook, the Digital Worker Identity Playbook, the Enterprise Single Sign-On Playbook, the Phishing-Resistant Authenticator Playbook, the ICAM Governance Framework, the Identity Fraud Detection Playbook, the Identity Lifecycle Management Playbook and the Privileged Identity Playbook.^[2]

The playbooks are written for agency staff. They are useful to a vendor for a different reason: they show the questions an agency will ask. Which attributes come from an authoritative source? How is a person deprovisioned on their last day? What evidence supports an access decision months later? This page tries to answer those questions for Identity Entry in the same order.

NIST SP 800-63: the assurance levels

NIST’s Digital Identity Guidelines define how strong identity proofing, authentication and federation need to be for a given risk. The fourth revision, SP 800-63-4, was published in July 2025 and replaces SP 800-63-3.^[7] The next chapter covers its three ladders, IAL, AAL and FAL, and where Identity Entry is and is not designed to help.

M-22-09 and zero trust

In January 2022, OMB issued M-22-09, the federal zero trust strategy.^[10] For identity, it calls for agency staff to use enterprise-managed identities, for phishing-resistant multi-factor authentication, and for agencies to consolidate identity systems so protections and monitoring apply consistently. It ties its goals to CISA’s Zero Trust Maturity Model, whose first pillar is identity.^[11] Chapter 14 covers both, with NIST SP 800-207 as the reference architecture.^[12]

5Assurance levels: IAL, AAL and FAL

NIST measures digital identity on three separate ladders. A service can sit on one ladder and be absent from the others.

SP 800-63-4 splits digital identity into three volumes. Volume A covers identity proofing and its Identity Assurance Levels. Volume B covers authentication and its Authenticator Assurance Levels. Volume C covers federation and its Federation Assurance Levels.^[8] Each ladder has three rungs. An agency picks the rung on each ladder from a risk assessment of the system involved.

Identity assurance: proofing a person

At IAL1, NIST says, the proofing process supports the real-world existence of the claimed identity. IAL2 requires more evidence and more rigorous processes. IAL3 adds a trained representative of the credential service provider, a proofing agent, who meets the applicant in an on-site attended session and collects at least one biometric.^[8] IAL1 and IAL2 can be done remotely or on site, with or without a person attending.

Identity Entry Verify was designed around the remote steps the guidelines describe. It collects evidence (the front and back of a government ID), validates it (the front and back must agree, the barcode or machine-readable zone check digits must hold, the document must be current and of a type the policy accepts), and verifies the person against it (a live selfie matched to the portrait on the ID, and a liveness check that defeats a printed photo, a screen or a replayed still). That is the shape of remote unattended proofing.

Shape is not certification. Identity Entry has not been assessed against SP 800-63A-4 by an agency or an accredited assessor, and it holds no IAL2 certification from Kantara or anyone else. It has no proofing agent and no on-site session, so it is not an IAL3 process. When the FICAM Architecture says agencies require a minimum of IAL3 for employees and contractors, it is describing the proofing behind the PIV card, and that proofing stays with the agency.^[1]

Authenticator assurance: logging in

AAL1 gives basic confidence that the person controls an authenticator bound to their account, and allows a single factor. AAL2 requires two distinct factors, and SP 800-63B-4 requires verifiers to offer at least one phishing-resistant option at that level. AAL3 requires a phishing-resistant authenticator with a private key that cannot be exported.^[8] The FICAM Architecture sets AAL2 as the minimum for federal employees and contractors.^[1]

Identity Entry is not an authenticator for agency systems, and nothing on this page should be read as a claim that it is. A face matched at a door is a physical entry decision under rules an organization sets. It does not replace a PIV card at a federal workstation, a FIDO2 key, or the multi-factor login an agency identity provider enforces.

Federation assurance: passing identity between systems

Federation is how one system, the identity provider, tells another, the relying party, who a person is. At FAL1 the identity provider signs its assertions and the relying party validates them. FAL2 adds strong protection against injected assertions, and requires the relying party to start the transaction. FAL3 adds an authenticator bound to the assertion that the relying party checks itself.^[8]

Sign in with Identity Entry is an OpenID Connect provider. It publishes a discovery document and its public signing keys, uses the authorization code flow started by the relying party, signs its ID tokens with RS256, and supports PKCE. Those are the building blocks the federation volume describes. As with proofing, Identity Entry has not been assessed at any FAL, and an agency that wants a level on paper would need that assessment done first.

6The capability map

All 21 FICAM services in one table, with each part of Identity Entry marked against them. Read it as a map of where to look, not a score.

The rows are the services GSA lists in the FICAM Architecture, grouped by practice area.^[1] The columns are the parts of Identity Entry: the four products, Sign in with Identity Entry, and the API with its webhooks. A filled circle means the part was designed to do that service’s job for the people it checks. A half circle means it does part of the job, or does it only inside its own scope. A dash means the service belongs to the agency.

Three patterns stand out. First, the identity column is the strongest: Verify was designed to do creation, proofing and registration, which is the front of the lifecycle. Second, access is strong only for physical entry: Identity Entry Access does policy administration and authorization for the places it is set up for, and it plays no part in logical access to agency networks. Third, federation and governance are partial by design. Policy alignment, the trust agreements between agencies, is agency work and no vendor can do it.

The chapters that follow take the five areas one at a time and explain each mark.

7Identity management: Verify and 360

The FICAM identity services are creation, proofing, provisioning, maintenance, aggregation and deactivation. Verify and 360 do most of the first two and part of the rest.

Creation and proofing: one link, one person

A check begins when an organization sends one private link to one person. The link is tied to that person and to a policy the organization chose. It stays open for 30 minutes, carries a short-lived token for that one check, and closes after use. Before anything is captured, the person reads and signs an authorization. Background searches and biometric comparison run only after that consent.

On their phone, the person photographs the front and back of a government ID. Identity Entry reads the name, date of birth, ID number, expiry and address; confirms the front and back agree; validates the barcode or machine-readable zone check digits; confirms the document is current and of a type the policy accepts; and checks a minimum age when one is set. A blurry or unreadable photo gets a request for a new one rather than a guess.

Then the person takes a selfie. The Face level scores how closely it matches the portrait on the ID and catches the same ID or selfie reused in another check. The Liveness level asks for a few random head movements, different for every check, and detects a printed photo, a screen held up to the camera, or the same still image sent twice. Every frame is tied to this one check, so an old recording cannot be replayed.

The seven levels and the five records

Each check is drawn as a ring. ID, Face and Liveness are always the outer three. Background adds four more inward: Watchlist screens the name against the US Treasury sanctions list and the FBI wanted list; Contact confirms the email domain can receive mail and the phone number is valid, and flags throwaway addresses and internet numbers; Bank confirms the person owns a US bank account through two small deposits; and Background searches public sex offender, arrest and jail booking records on name and date of birth.

Identity Entry 360 keeps those seven and adds five records: driving record, education, tax filing, security clearance and criminal records. Access adds one ring of its own, Door entry, to the outer three. In the middle of every mark sits the decision.

Pass, Caution or Fail, and never a silent gap

Every check ends in one of three answers. Pass means every check the policy asked for was proven. Fail means something was proven wrong: a different face behind the ID, an expired document, a document type the policy refuses. Caution means a person needs to look. A name match in public records is always Caution and never an automatic Fail, because a name can belong to someone else.

A check that could not be completed is never counted as a Pass. The organization’s policy decides whether it becomes Caution or Fail. That rule holds for every record source: a source that is not connected shows as not connected, and the ring for it never fills.

What answers today in 360, and what waits

Each 360 record source is answered only when its provider connection is live. Driving record and education are answered through a records provider once that connection is switched on. Criminal records follow the same rule, source by source. Two sources wait on the government itself:

That honesty is the point of the design. An agency reading a 360 report can see which records were answered, which were claimed, and which were not connected, record by record, and decide what to do about each.

Provisioning, maintenance, aggregation and deactivation

Identity Entry does not provision agency accounts. It hands the agency what provisioning needs: a decision, the evidence behind it and the reason, delivered by a signed webhook or read through the API. A person who returns is matched to the profile they already have, so a second check builds on the first rather than starting a stranger’s record. That is the part of aggregation Identity Entry does.

Identity profiles, including ID photos, selfies and the face record made from them, are kept for up to 10 years after the person’s most recent check, so a returning person can be confirmed without starting over. A person can have the profile deleted sooner at any time by emailing team@identityentry.com or by deleting their Identity Entry account. Where a state law sets a shorter period for biometric information, such as Illinois, Identity Entry follows the shorter period for residents of that state. The organization has 7 days to review the results of each check. The full schedule is in the Data Retention policy.

Who decides, and which laws apply

Identity Entry supplies information to support a decision. The decision belongs to the organization that ran the check. Where background information is used for employment, housing, credit, insurance or a similar decision, the Fair Credit Reporting Act and state laws may apply, with their own disclosures and notices. The organization decides whether they apply to its use and gives every notice they require, as the Background Check Notice explains.

8Credential management: the reusable profile

FICAM’s credential services are sponsorship, registration, generation and issuance, maintenance and revocation. Identity Entry’s answer to them is a profile the person controls, which is a different thing from a PIV card.

Federal credentials are cryptographic objects. A PIV card holds private keys, certificates and a photo, and it authenticates a person to a federal system or door under FIPS 201.^[4] Identity Entry issues nothing of the kind. What it keeps is a verified record of a person: the evidence from their checks, the decisions, and the face record that lets them be confirmed again later. The person carries nothing; the profile stays with Identity Entry under the person’s control.

That profile does several credential jobs, each in a narrower form than a PIV card would.

Verified once, reused, revocable

The first check does the heavy work. After that, the same person can be confirmed against the profile instead of repeating every step. Identity Entry Access depends on this: a returning guest reuses their profile and walks in on a face scan, with no new selfie. For an agency, the same reuse means a contractor who was proofed for one task order does not start from nothing for the next, provided the agency’s policy accepts the earlier result.

Reuse never removes the person’s say. They choose which companies may use the profile and can take that choice back.

Identity Entry Shield: the person’s own account

Identity Entry Shield costs $100 a year and is paid by the person. It is their own Identity Entry account. With Shield, a person sees what Identity Entry holds and has found about them, gets an email alert for every check started on them with the company and the time, sees which company ran each check and what it saw, and can lock new checks until they approve them. If their ID is presented with a different face, the check fails. Over time they can upload their own documents, such as degrees and licenses, for Identity Entry to verify.

In FICAM terms, Shield gives the subject of the record a hand in its maintenance and revocation. Federal enterprise identity rarely offers that, because the agency owns the record. For a contractor whose profile is reused across several organizations, it is the control that keeps reuse fair.

9Access management: Identity Entry Access

FICAM’s access services are policy administration, authentication, authorization and privileged access. Identity Entry Access does them at a physical door.

Identity Entry Access

Face-based entry for events, buildings and in-person arrivals. A phone or tablet at the door is all staff need.

$2 for each person on the entry list.

How a door works

An organization creates an entry list for a place: an event, a site, a building or a departure. Each person on it verifies once, or reuses the profile they already have, and agrees to face-based entry when they enroll. At the door, staff open the door app on any phone or tablet. The camera scans the person’s face, and a match opens the way only for someone holding a pass for that place.

The answer on screen is short and unambiguous. Welcome, go in. Already entered, when the pass has been used and the rules allow one entry. See staff, when the face is not on the list or the pass does not cover this door. Staff can admit a person by hand, and the app records who admitted them and why.

The controls an access officer asks about

Mapped to the FICAM access services

Digital policy administration. The organization writes the door rules: which list, which zones, which days, whether re-entry is allowed, and whether the door runs on face only or ticket then face. On the Verify side, the workspace policy decides which checks run and what an incomplete check becomes.

Authentication. At the door, the face is matched against the enrolled profile. This authenticates the person to the door, under the organization’s own rules. It is not an authenticator assurance level under SP 800-63B, and it is not a login to any system.

Authorization. The pass is the authorization: this person, this place, these days, these zones. In the FICAM scale of access models, this is a list with attribute rules on top.^[1]

Privileged access. The privileged accounts in Identity Entry are the staff who manage lists and enroll people. They are separated by role, and API keys belong to one workspace with their own permissions.

Where Access does not go

Identity Entry Access does not connect to a federal physical access control system, does not read PIV cards, and does not decide access to agency networks or applications. It is a door for the places that do not run PACS: an offsite training event, a vendor conference, a temporary site, a building an agency or contractor leases outside the federal estate. Where a facility runs PACS on PIV, that system stays in charge.

10Federation: Sign in with Identity Entry, webhooks and the API

GSA’s federation services are policy alignment, the authentication broker and attribute exchange. Identity Entry offers the second and part of the third.

Sign in with Identity Entry

Sign in with Identity Entry is an OpenID Connect provider, the same standard behind the familiar sign-in buttons on consumer sites. A relying party, any website or application with a custom OpenID Connect login option, adds it with a client ID, a secret and a discovery address from the Identity Entry Connections page. No code is required on platforms that already support OpenID Connect.

When a person signs in, they verify with Identity Entry, or an earlier Pass is reused. The relying party receives a one-time code and exchanges it for an ID token and an access token. The token carries a small set of claims:

In FICAM terms this is an authentication broker: it turns an authentication event into an assertion with claims about the person and the transaction.^[1] The building blocks match what SP 800-63C-4 describes for federation: signed assertions validated by the relying party, and flows the relying party starts.^[8] No FAL has been assessed, and Sign in with Identity Entry is not a login to federal systems that require PIV.

Signed webhooks and the API

Attribute exchange is the other half of federation: getting identity attributes from one system to another so the second can make a decision.^[1] Identity Entry does this with webhooks and an API. Every decision can be pushed to the organization’s own system as a webhook. Every webhook carries an HMAC-SHA256 signature over its timestamp and its exact body, and the receiving system confirms both before it acts. The same checks are available through the website, the API and the MCP server, at the same prices. The developer reference lists the endpoints.

No-code connections

Not every organization that vets people runs its own software. Identity Entry joins the tools they already use:

Policy alignment stays with the agencies

The first federation service in the architecture is policy alignment: the authorities, policies and agreements that let one party trust another.^[1] That is a relationship between agencies, and between an agency and any provider it chooses to accept. Identity Entry can supply documentation and answer questions. The decision to trust any external identity provider, and at what level, belongs to the agency.

11Governance: evidence, reasons and the audit history

GSA lists identity governance, analytics and mitigation. Each one depends on being able to explain a decision long after it was made.

Months after a contractor was cleared to start work, someone may ask why. An inspector, a contracting officer, the contractor themselves. The answer has to be on the record, with the evidence that supported it and the name of whoever decided.

Identity Entry keeps every decision with three things beside it: the evidence, the reason and the owner. The evidence is the result of each check, ring by ring. The reason is a plain statement of why the case came out the way it did. The owner is the person, the policy or the engine that made the call. Every decision recorded on a check is kept in the workspace audit log with who made it, when and why.

The three answers, by design

Results are always Pass, Caution or Fail. Caution is not an afterthought; it is how Identity Entry routes uncertainty to a person instead of hiding it inside a confident score. A public-record name match is always Caution. A check that could not be completed is never a Pass. The review queue shows a case in full before anyone records a decision, and that decision joins the audit log with its reason.

Consent on the record

Every check starts with the person’s own link and a signed authorization. For biometric comparison and for background searches, the person accepts before anything runs, and the business records its purpose for a background search. Those records sit with the check, so the question of whether the person agreed has a document behind its answer.

Mapped to the governance services

Protection that supports the record

Photos are encrypted with AES-GCM before they are stored, with the check they belong to bound into the encryption, and they can be retrieved only through a signed-in request from the workspace that requested the check. Every API key belongs to one workspace and carries its own permissions. Identity Entry does not collect Social Security numbers. The security page describes each measure and states plainly that it is not a certification.

12The contractor vetting lifecycle

Onboard, proof, credential, access, monitor, offboard. Six steps, two lanes: what the agency or prime does, and what Identity Entry does.

1. Onboard

The agency or prime contractor decides who needs vetting and why. In Identity Entry, that becomes one private link sent to one person, tied to a policy. The contractor opens it on their phone, reads what will be checked, and signs the authorization. A link that closes before they finish can be sent again; the old one cannot be reused.

2. Proof

The policy sets the checks. For a site visit, the ID check may be enough. For work near money or sensitive systems, Background or 360 fits better. Identity Entry runs the checks and returns Pass, Caution or Fail with the evidence, by webhook or in the console. Caution cases wait in the review queue for a person on the agency side.

3. Credential

Where the role needs a PIV card or a CAC, the agency sponsors one and issues it under FIPS 201, after the background investigation has started.^[4] Identity Entry’s result can inform the decision to sponsor, and the agency remains the issuer. Where the role does not need a federal credential, the reusable Identity Entry profile is the record of who the person is.

4. Access

Federal systems and PIV-controlled doors stay with the agency’s identity provider and PACS. For the places outside them, Identity Entry Access can run the door: a training week at a rented venue, a contractor’s own site, a vendor event. The contractor walks in on a face scan, and staff see who entered and when.

5. Monitor

Identity Entry runs a check when an organization sends one. An agency that wants a fresh look before an option year, a new site or a new task order sends a new check, and the contractor confirms against the profile they already have. Identity Entry does not run continuous evaluation against government records; that remains part of federal personnel vetting. If the contractor has Shield, they receive an alert for every check started on them.

6. Offboard

On the last day, the agency revokes the PIV card and accounts. In Identity Entry, the organization removes the person’s passes, so their face no longer opens any door on those lists. The decisions stay in the audit log, so the history of who was cleared, when and why survives the contract. The person’s profile follows the retention schedule, and they can have it deleted sooner.

13Beside PIV, CAC and agency identity providers

The PIV card and the agency identity provider sit at the center of federal enterprise identity. Identity Entry sits on either side of that center, never inside it.

Before sponsorship

An agency or a prime contractor often needs to know who a person is before it commits to sponsoring a credential. Is the ID genuine? Does the face match? Does the name appear on the Treasury sanctions list or the FBI wanted list? Identity Entry Verify and 360 answer those questions from the person’s own phone, with the evidence kept. The answer can feed the decision to sponsor. It does not substitute for the proofing FIPS 201 requires before a PIV card is issued.^[4]

Outside the PIV boundary

Many people an agency works with never receive a PIV card: short-term contractors, subcontractor staff, visitors to an offsite event, vendors at a conference. Many places they meet are outside federal PACS. Identity Entry Access gives those places a door with a verified list behind it, without asking anyone to carry a federal credential.

Sign in with Identity Entry serves the same space online. A contractor portal, a training registration site or a vendor’s own application can accept it as one way for a verified person to sign in. Federal systems that require PIV or an agency identity provider keep requiring them.

Alongside the agency identity provider

M-22-09 asks agencies to consolidate identity systems and to centrally support any non-PIV authenticators in their enterprise identity management systems.^[10] An agency that wants Identity Entry results inside its own identity stack would bring them in through the API or webhooks, as attributes about a person, under its own governance. Identity Entry does not become an agency identity store.

14Zero trust and the identity pillar

Zero trust treats every request as untrusted until the evidence says otherwise. Identity Entry was designed around the same habit at a smaller scale: no result passes without proof.

The federal strategy

M-22-09 sets the federal zero trust strategy. Its identity goal is that agency staff use enterprise-managed identities to reach the applications they use, protected by phishing-resistant multi-factor authentication. It names PIV and the W3C Web Authentication standard as phishing-resistant options, and tells agencies to stop requiring special characters and regular password rotation.^[10]

CISA’s Zero Trust Maturity Model, version 2.0, organizes the work into five pillars: identity, devices, networks, applications and workloads, and data. Each moves through four stages: traditional, initial, advanced and optimal. Version 2.0 added an access management function to the identity pillar, alongside authentication, identity stores, risk assessments, visibility and analytics, automation and orchestration, and governance.^[11]

The reference architecture

NIST SP 800-207 describes zero trust in logical components. A policy engine decides whether to grant access. A policy administrator acts on that decision. A policy enforcement point sits in front of the resource, opening and closing the connection.^[12] The engine draws on signals: identity, credentials, history, threat information.

The identity pillar, function by function

Read the table as a list of contributions to an agency’s program, not as a maturity rating. CISA’s stages describe an agency’s whole enterprise. A single vendor cannot move an agency from one stage to another on its own.

15What Identity Entry is not (yet)

Every alignment on this page is design intent. Here is the list of things Identity Entry does not hold, does not do, or cannot do without a government partner.

Not a PIV or CAC issuer

Identity Entry does not issue PIV cards, PIV-I cards, CACs, derived PIV credentials or any smart card. It does not run a FIPS 201 issuance process, and its results do not replace the identity proofing FIPS 201 requires before a card is issued.

Not FedRAMP authorized

Identity Entry holds no FedRAMP authorization at any impact level and no agency Authority to Operate. An agency that needs one for a cloud service would treat that as a condition to settle before any use that requires it.

Not certified at any NIST assurance level

Identity Entry has not been assessed or certified at any IAL, AAL or FAL under SP 800-63. It holds no Kantara certification, at IAL2 or any other level. Where this page says “designed around” or “maps to,” it describes design intent, not an assessment.

No security certifications

Identity Entry makes no claim of SOC 2, ISO 27001, regulatory compliance, uptime, accuracy or speed. The security page describes how the product is built. Independent assurance for a deployment is gathered separately.

Not an authenticator for agency systems

Identity Entry is not a phishing-resistant authenticator and is not used to log in to federal systems. A face match at a door is a physical entry decision under an organization’s own rules.

Security clearance confirmation needs a sponsoring agency

Identity Entry 360 records the clearance level and agency a person states, as claimed and not yet confirmed. Confirming it requires a sponsoring agency or a cleared facility with access to the government’s personnel security systems.

Tax transcripts need IRS IVES

A tax transcript comes through the IRS Income Verification Express Service, from an authorized participant, with the person’s signed Form 4506-C. Identity Entry is not an IVES participant, so tax filing shows not connected yet and never passes.

Not a federal background investigation

Background and 360 search the permitted sources each check connects to. They are not a federal background investigation, a Tier investigation or continuous evaluation, and a clear result means the permitted sources returned no match, not that no record exists anywhere.

Not connected to federal PACS

Identity Entry Access does not read PIV cards and does not connect to a federal physical access control system. It runs doors outside that system.

Two of those limits, clearance and tax, are paths that open only with a government partner. The IRS sets who may request a transcript through IVES.^[13] The agencies that hold clearance records decide who may confirm them. Until either path is connected, Identity Entry shows the record as claimed or not connected, and the ring for it does not fill.

The rest describe what Identity Entry is today: a commercial service for identity verification, biometric entry and background screening, with a reusable profile the person controls. It is designed around the FICAM model so that an agency can see exactly where it fits, and exactly where it stops.

16Getting started

Run a check on yourself first. You see exactly what a contractor sees, and exactly what your team sees afterwards.

Each product is bought on its own or together. You pay once for each person you check, and you choose at checkout how to pay: as you go each month, prepaid, or under a long-term agreement. Prices are the same on the website, the API and the MCP server, and may change with notice. The pricing page adds up a total before you buy.

A first week, for a program office

1. Create a workspace and choose a policy: ID check for site visitors, Background for staff near money or systems, 360 where you need government level vetting.
2. Run one check on yourself. Read the authorization, take the photos, and look at the result your reviewers will see.
3. Connect your system with a signed webhook, the API, or Sign in with Identity Entry. Or skip this and work from the console.
4. Send links to a first group of contractors and work the Caution cases in the review queue.
5. For an event or site, create an entry list in Identity Entry Access and open the door app on a phone or tablet.

Questions about a specific deployment, a security review or a procurement vehicle go through the contact page.

17Questions program offices ask

18Sources

Every federal statement on this page comes from one of these primary documents. Product statements come from Identity Entry’s own pages and policies.

1. FICAM Architecture, version 3.3U.S. General Services Administration, IDManagement.gov, June 2023.
2. FICAM PlaybooksU.S. General Services Administration, IDManagement.gov, Updated through 2026.
3. Homeland Security Presidential Directive 12: Policy for a Common Identification Standard for Federal Employees and ContractorsThe White House, published by the U.S. Department of Homeland Security, August 2004.
4. FIPS 201-3: Personal Identity Verification (PIV) of Federal Employees and ContractorsNational Institute of Standards and Technology, January 2022.
5. PIV 101U.S. General Services Administration, IDManagement.gov, Current.
6. OMB Memorandum M-19-17: Enabling Mission Delivery through Improved Identity, Credential, and Access ManagementOffice of Management and Budget, May 21, 2019.
7. NIST SP 800-63-4: Digital Identity Guidelines (with volumes 63A-4, 63B-4 and 63C-4)National Institute of Standards and Technology, July 2025.
8. NIST SP 800-63-4, online editionNational Institute of Standards and Technology, July 2025.
9. NIST SP 800-63-3: Digital Identity Guidelines (superseded by 800-63-4)National Institute of Standards and Technology, June 2017, updated March 2020.
10. OMB Memorandum M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity PrinciplesOffice of Management and Budget, January 26, 2022.
11. Zero Trust Maturity Model, version 2.0Cybersecurity and Infrastructure Security Agency, April 2023.
12. NIST SP 800-207: Zero Trust ArchitectureNational Institute of Standards and Technology, August 2020.
13. Income Verification Express Service (IVES) and Form 4506-CInternal Revenue Service, Current.