Contractors need privileged badges and elevated accounts for datacenter work. What must happen before those credentials are issued?
Select an answer to reveal the explanation.
Short Explanation
Before you hand a contractor the keys to the server room, make sure they are who the paperwork says they are. Identity proofing is that check—do it first, not after something goes wrong.
Full Explanation
Privileged badges and elevated datacenter accounts for contractors must not be issued on trust of paperwork alone. Identity proofing verifies that the person receiving physical and logical privilege is the individual the contracting company claimed—using government ID checks, documented processes, and enrollment into the county's identity and badge systems before keys or admin credentials exist. For municipal datacenters, that front-loaded assurance prevents attackers or impostors from obtaining privileged access under a legitimate-looking contractor name.
Issuing the badge first and verifying identity only after an incident inverts the control sequence and leaves a window where unverified privileged access is already live. Reusing a former employee's badge number for convenience creates identity confusion in access logs and can inherit residual rights or audit ambiguity. Skipping proofing because a company email 'looks legitimate' confuses email deliverability with identity assurance and is trivial for social engineers to abuse.
Exam caveat: identity proofing is distinct from authorization—knowing who someone is does not automatically justify Domain Admin; pair proofing with least privilege and time-bounded contractor roles. Also align contractor proofing with background-check and sponsor-approval policies where required.
Operational check: require completed proofing and sponsor approval records before badge print and account creation, audit recent contractor enrollments for missing proofing evidence, and confirm badge and account disablement workflows trigger together when the contract ends.