TOEIC Link Badge Access and Visitor Check-In Vocabulary: The Issue-Grant-Log-Revoke Cluster for Part 4 and Part 7
In TOEIC Link, a security badge is a permission that turns on and off, and ETS tests whether you know exactly which state it is in. A facilities team issues a badge to a new hire, programs access to certain floors, and the employee swipes in at the turnstile each morning. A recorded message tells staff that badges will be reprogrammed over the weekend and old cards will stop working on Monday (Part 4). An email shows a visitor who was pre-registered at the front desk, needs a temporary pass, and must be escorted above the lobby, and a question asks whether the visitor can enter alone (Part 7). Because building access always has the same moving parts — a badge that is issued, an entry that is logged, and a credential that expires or is revoked — ETS can set them against each other and leave exactly one answer standing. Miss a term like issue, activate, deactivate, escort, or temporary pass and a status question can slip past in one move.
This article organizes the cluster by the way building access is controlled — issue the credential, grant the entry, log the visitor, revoke the access — because that structure is exactly how ETS threads the announcements together. Because a badge is one of several standing entry benefits a facilities team manages, pair this first with the parking permit and garage access cluster — a building badge and a garage permit are the two ends of the same "who is allowed in" decision. And because a badge reader that fails is a facilities problem, not a policy one, contrast this with the facility maintenance and repair request cluster, where a broken card reader becomes a work order rather than a revoked credential.
Why badge access and visitor check-in vocabulary is overweighted
Reason 1 — a credential has a status that flips. Requested, issued, active, expired, or deactivated — a badge sits in exactly one state, and each state is a plausible distractor for the others. When a question asks whether someone can get in, only the active status settles it — exactly what a Part 4 announcement is built to test.
Reason 2 — the person and the permission are two separate variables. Access can change because the credential changed (badge deactivated, reprogrammed, expired) or because the person's status changed (pre-registered, escorted, denied) — and ETS loves the gap between the two. The question "Why couldn't they enter?" has exactly one answer, and it turns on whether the card failed or the person was not cleared.
Reason 3 — the access terms are fixed conventions. Issue, activate, deactivate, swipe in, escort, temporary pass, pre-register mean the same thing across every building, badge, and check-in desk. That rigidity makes the cluster perfectly testable — and perfectly learnable. The collocation, not the isolated word, is the unit of memory.
The cluster, organized by the way building access is controlled
Stage 1 — issue the credential
Verbs and collocations: issue a badge, program access, assign a credential, activate the card, set access levels.
Nouns: badge, credential, access level, keycard, security clearance.
Access starts when the team issues a badge and programs access to the right floors and doors. A Part 4 announcement tells new hires to pick up their badge at security; a Part 7 question asking who can reach a restricted floor points to the access level, not the check-in log. The trap offers a visitor detail to a reader asked about an employee credential.
Stage 2 — grant the entry
Verbs and collocations: swipe in, tap the reader, badge in, hold the door, tailgate through.
Nouns: turnstile, card reader, entry, access point, lobby.
Each day the credential grants entry: an employee swipes in at the turnstile or taps the reader at an access point. A Part 4 reminder warns staff not to let others tailgate through on one badge; a Part 7 thread about a jammed reader asks whether the card was denied or the reader was broken — a permission failure versus a hardware failure. The reader who separates the two answers cleanly.
Stage 3 — log the visitor
Verbs and collocations: pre-register a visitor, sign in at the front desk, issue a temporary pass, escort a guest, sign out.
Nouns: visitor log, front desk, temporary pass, escort, sign-in sheet.
Visitors go through a separate path: they are pre-registered, they sign in at the front desk, receive a temporary pass, and are escorted beyond the lobby. A Part 4 message tells a host to meet their guest downstairs; a Part 7 question asking whether a visitor may go up alone points to the escort rule, not the badge program. A pre-registered visitor and a cleared-to-roam visitor are different states.
Stage 4 — revoke the access
Verbs and collocations: deactivate a badge, revoke access, reprogram the cards, report a lost badge, replace a credential.
Nouns: deactivation, expiration, lost badge, reissue, access change.
Finally, access ends or changes: a badge is deactivated when someone leaves, cards are reprogrammed after a security change, or a lost badge is reported and reissued. A Part 4 announcement says old cards will stop working after a cutoff; a Part 7 notice pairing a reprogramming date with a pickup instruction asks whether the badge was cancelled or simply needs updating. The reader who knows deactivated means gone and reprogrammed means still valid picks the one that fits.
The paraphrase traps ETS builds on this cluster
Issued vs. requested. An issued badge is in hand and working; a requested one is still being processed. A question asking whether a new hire can enter rewards the reader who keeps the two apart — "your badge is being made" is not "your badge is ready."
Card failed vs. person not cleared. A dead reader or a deactivated card is a credential problem; an unregistered visitor is a person problem. ETS offers "the badge reader is broken" to the reader who saw an entry denied and assumed the hardware, when the visitor was simply never pre-registered.
Deactivated vs. reprogrammed. A deactivated badge is permanently off; a reprogrammed one still works after an update. A question about whether an old card is usable rewards the reader who reads which one the announcement actually states.
How to drill this cluster
Practice by breaking one access message into its two variables. Take a notice — "All employee badges will be reprogrammed this weekend; tap the new reader by the north entrance starting Monday. Visitors must still be pre-registered and escorted above the lobby" — and label each piece: reprogrammed and new reader are credential/hardware changes for employees, pre-registered and escorted are person-status rules for visitors, and no badge was deactivated. When you can split any message into "what changed about the card" and "what's required of the person," the Part 4 question stops being a listening exercise and becomes a sorting exercise.
Pair this cluster with the parking permit and garage access cluster: a garage permit and a building badge run on the same issue-activate-revoke logic, so a single "your access is changing" message often touches both. Studied together, they cover almost every "who is allowed into the building" message ETS can write.
The one-sentence version
Building access has four moving parts — a badge that is issued and programmed, an entry logged at a reader, a visitor who is pre-registered and escorted, and the revocation that deactivates, reprograms, or reissues a credential — and TOEIC Link tests whether you can tell a card that failed from a person who was never cleared, and a badge that is deactivated from one that merely needs an update.