Why identity verification matters
Identity verification in access control is the consistent process of confirming that a person is who they claim to be and that the credential they present is valid right now for the requested access. A credential (badge, pass, QR code, mobile token) is evidence of identity and/or authorization. Your job is to validate both: (1) the person-to-credential match and (2) the credential-to-permission match.
1) Identity sources and credential types
Different sites accept different identity sources. Treat each source as having a specific trust level and a specific way to validate it.
Government-issued ID
- What it proves: Legal identity (name, date of birth) and usually a photo.
- Typical use: First-time visitors, contractors, deliveries requiring age verification or regulated access.
- Validation focus: Photo match, document integrity, expiration date, and signs of tampering.
Company badge (employee/contractor credential)
- What it proves: Enrollment in the organization’s credential system; may encode access rights.
- Typical use: Routine entry for staff and long-term contractors.
- Validation focus: Photo/name match, badge status (active/disabled), correct badge type (employee vs contractor), and whether access rights are current.
Visitor pass (temporary credential)
- What it proves: A temporary authorization tied to a visit record (host, purpose, time window).
- Typical use: Guests, interviews, short-term vendors.
- Validation focus: Valid time window, correct host/appointment, correct areas allowed, and whether it was issued to the same person presenting it.
QR codes (printed or on-screen)
- What it proves: Usually a reference to a visit record or a one-time token; trust depends on how it’s generated and protected.
- Typical use: Pre-registered visitors, event check-in, delivery appointments.
- Validation focus: Scan result matches the person and appointment; token is unexpired and unused (if one-time); QR is not a screenshot reuse (where applicable).
Mobile credentials (wallet/app-based)
- What it proves: A cryptographic token tied to a device and user account; often supports rapid revocation.
- Typical use: Employees, contractors, frequent visitors.
- Validation focus: App shows correct identity; credential is active; device is presenting the credential live (not a static image); access rights match the requested entry.
Quick comparison table
| Credential type | Best for | Main risks | Best validation method |
|---|---|---|---|
| Government ID | Establishing identity | Forgery, expired ID | Photo match + integrity checks |
| Company badge | Routine access | Borrowed badge, not revoked | Photo match + system status check |
| Visitor pass | Temporary access | Wrong person, wrong time window | Match to visit record + time/area limits |
| QR code | Fast check-in | Screenshot reuse, forwarded code | Scan + verify token state + identity match |
| Mobile credential | High-control access | Shared phone, compromised account | Live app display + system status check |
2) Credential lifecycle: issuance to replacement
Credentials are only trustworthy when they are managed through a controlled lifecycle. Understanding the lifecycle helps you spot when a credential should not be accepted.
Issuance
- What happens: Identity is enrolled, a credential is created, and a record is stored (badge number, owner, type, allowed areas, start/end dates).
- What you should expect at the checkpoint: The credential should look consistent with the organization’s standard (format, photo placement, security features, color coding).
Activation
- What happens: Credential becomes usable (often after training, approval, or start date).
- Checkpoint implication: A newly issued badge may exist physically but still be inactive in the system. If your system check shows “inactive/pending,” treat it as not valid.
Expiration
- What happens: Credential validity ends at a date/time (end of contract, visitor window, event end).
- Checkpoint implication: Expired credentials are not acceptable even if the person “was here yesterday.” Use the current timestamp and the credential’s allowed window.
Revocation (immediate disablement)
- What happens: Credential is disabled due to termination, loss, policy violation, or security concern.
- Checkpoint implication: A revoked badge may still look fine. Always rely on status checks where available.
Replacement (lost, stolen, damaged, role change)
- What happens: Old credential should be deactivated; a new one is issued.
- Checkpoint implication: If someone presents an “old badge,” it should fail status checks. If they claim it’s their only badge, escalate rather than “making an exception.”
Lifecycle control checklist (for supervisors/process owners)
- Every credential has an owner, type, and unique identifier.
- Start/end dates are enforced (especially for visitors and contractors).
- Lost/stolen reports trigger immediate revocation.
- Replacement automatically disables the prior credential.
- Audit logs exist for issuance, changes, and revocation actions.
3) Consistent validation steps (a repeatable method)
Use the same sequence every time. Consistency reduces errors and prevents “social engineering” from pushing you into shortcuts.
Step-by-step validation workflow
- Match the person to the credential
- Compare face to photo (if present). Look for stable features (eye spacing, nose shape, facial structure) rather than hair or facial hair.
- Confirm name (and company/host where relevant) by asking an open question: “What’s your full name and who are you here to see?” rather than “Are you John here for Sarah?”
- If no photo credential is used (some QR/visitor flows), request a secondary check per policy (often government ID) to bind the token to the person.
- Check credential integrity
- Inspect physical badges/passes for tampering: peeling laminate, uneven edges, altered text, inconsistent fonts, missing hologram/markings (if your organization uses them).
- For QR/mobile: ensure it is presented live (scan the code; do not accept a typed number if scanning is required by procedure).
- Confirm the credential type matches the situation (e.g., visitor pass for a visitor, not an employee badge “forgotten at home” scenario unless policy allows an alternate verification path).
- Confirm current access rights (system check)
- Verify status:
ActivevsInactive/Expired/Revoked. - Verify scope: correct site, building, and area permissions for the requested entry.
- Verify time rules: allowed hours/days, visit window, contractor schedule.
- If your checkpoint does not have system visibility, follow the site’s alternate verification method (e.g., call the access desk/host) rather than guessing.
- Verify status:
- Verify host/appointment (when applicable)
- Check the visit record: host name, company/department, purpose, expected time, and any special instructions (escort required, restricted areas).
- Contact the host using official channels if the record is missing, unclear, or the visitor’s story changes.
- For deliveries: verify delivery appointment/reference and receiving location; confirm the receiver is expecting the shipment if required.
Example: visitor with a pre-registration QR code
1) Ask: “What’s your full name and who are you visiting?” (open question) 2) Scan QR code → confirm it pulls up the same name and host 3) Check time window and site location match 4) If policy requires: verify government ID matches the visit record name 5) Issue visitor pass and note any escort requirementExample: employee badge fails system check
1) Keep the interaction calm and neutral 2) Re-scan/retry once (rule out reader error) 3) If still inactive/disabled: deny entry through controlled doors 4) Escalate to security supervisor/access admin per procedure 5) Document: badge ID, name, time, door, system message, actions takenDecision rules: deny, escalate, document
Use clear rules so decisions are defensible and consistent.
- Listen to the audio with the screen off.
- Earn a certificate upon completion.
- Over 5000 courses for you to explore!
Download the app
When to deny access (do not allow entry)
- Credential status is expired, revoked, or disabled in the system.
- Person does not match the credential photo or identity record.
- Credential appears altered or counterfeit (integrity concerns).
- No valid appointment/host confirmation for a visitor when required.
- Person refuses required verification steps (e.g., refuses to present ID where policy mandates it).
When to escalate (pause entry and involve the right party)
- System is down and you cannot confirm status, but the person claims urgent need.
- Visitor record exists but details conflict (wrong host, wrong time, wrong site).
- Employee/contractor claims badge was just issued or recently replaced but system shows inactive.
- Suspicious behavior indicators appear (see red flags) even if the credential looks valid.
How to document the reason (minimum necessary, factual)
- Record objective facts: date/time, checkpoint location, credential type/ID number (if permitted), system status message, and what was requested.
- Describe behavior factually (what you observed), not interpretations. Example: “Subject avoided camera and repeatedly attempted to enter behind others” rather than “Subject seemed guilty.”
- Record actions taken: denied entry, host called, supervisor notified, incident report number.
- Do not record sensitive personal data unless required (see privacy section).
4) Common red flags and how to respond
Red flags do not automatically mean wrongdoing, but they do require stricter adherence to validation steps and often escalation.
Altered or suspicious IDs
- Red flags: Blurry printing, mismatched fonts, peeling laminate, photo looks re-glued, missing expected security features, expiration date altered.
- Response: Do not argue about authenticity. Deny or escalate per policy. Offer an alternate verification path if approved (e.g., secondary ID + host confirmation), but do not accept a questionable document as proof.
Mismatched photos or physical description
- Red flags: Photo clearly does not match; name/age/height inconsistent with the person; person avoids showing face.
- Response: Pause entry. Ask neutral clarifying questions. If mismatch remains, deny and escalate.
Borrowed badges and “tailgating by credential”
- Red flags: Person hesitates when asked their name/department; badge photo is partially covered; badge is presented quickly then hidden; multiple people attempt to enter on one badge.
- Response: Require each person to present their own credential. If someone claims they forgot theirs, follow the approved alternate verification process; otherwise deny.
Suspicious behavior patterns
- Red flags: Rushing you, creating distractions, insisting on exceptions, refusing standard steps, inconsistent story, loitering near doors, repeated attempts at different entrances.
- Response: Slow the process down, stick to the script, and escalate early. Document the specific behaviors observed.
5) Privacy considerations in identity verification
Access control often involves personal data (names, photos, ID numbers, visit details). Handle it with care: collect the minimum necessary, use it only for access decisions, and store it securely.
Minimum necessary collection
- Collect only what you need to verify identity and authorization (e.g., name + host + time window). Avoid unnecessary details (full date of birth, home address) unless required by policy or regulation.
- If you must view a government ID, do not copy or record fields that are not required for the access decision.
- For visitor logs, prefer internal identifiers (visit ID) over sensitive ID numbers when possible.
Handling and viewing personal data
- Do not announce personal details loudly at the checkpoint.
- Keep screens angled away from public view; do not leave visitor lists visible.
- Return IDs promptly; do not hold personal documents longer than required.
Secure storage of logs and records
- Store access logs and visitor records in approved systems with role-based access.
- Follow retention rules: keep records only as long as required, then dispose securely.
- Protect printed logs: keep in locked storage; shred when disposal is authorized.
- Do not use personal devices (photos, notes apps) to record IDs or incidents unless explicitly authorized.
Documenting incidents without over-collecting
When you document a denial or escalation, include enough detail to support follow-up while avoiding unnecessary sensitive data.
- Good: “Visitor John Smith, pre-registration QR did not match host listed; host unreachable; entry denied; supervisor notified.”
- Avoid: Recording full driver’s license number, home address, or unrelated personal attributes unless required.