How to design and operate access control for third parties, service providers, and contractors: sponsor, validity, zones, credentials, vehicles, revocation, and audit.
Check it out!
Access control for third parties, service providers, and contractors should transform an external relationship—typically limited by company, contract, service, location, and period—into specific, temporary, and auditable physical authorizations. The objective is not to register the service provider as if they were an internal employee, but to ensure that they access only the necessary areas, during authorized hours, and while the conditions that justify that access remain valid.
The risk lies in the dispersed nature of the relationship. Third parties may work in multiple areas, use vehicles, work outside business hours, return over several months, and depend on different teams for approval. When the process is manual, credentials without expiration, people linked to terminated contracts, duplicate registrations, overly broad authorizations for convenience, and difficulty identifying who sponsored each access request can emerge.
From an engineering standpoint, the process must relate the person, company, contract or work order, sponsor, prerequisites, areas, schedules, credential, vehicle, escort requirement, start date, end date, renewal rules, and revocation procedure. The architecture must transform these relationships into verifiable states in the EACS, with logs, integration, and acceptance criteria.
Third Parties Are Neither Visitors nor Internal Employees
The architecture of an access control system connects identity, authorization, barriers, infrastructure, and operations. In this context, the design must preserve this system-level view and translate specific decisions into verifiable requirements.
Visitors typically have a short stay and a specific purpose. Internal employees are subject to the corporate HR lifecycle. Service providers may fall between these extremes: they may perform recurring activities, belong to an external company, be tied to a contract, have safety requirements, and need access for weeks, months, or years.
This distinction matters because governance must follow the actual relationship. A visitor may be authorized for a few hours; a recurring service provider requires history, sponsorship, validity, recertification, and termination. A resident contractor may require a process similar to that of an internal employee, while preserving the link to the contracted company and the instrument that justifies their presence.
| Population | Typical relationship | Validity | Governance |
| Visitor | one-time invitation | hours or days | sponsor + expiration |
| Recurring service provider | contract or service | weeks or months | company + contract + profile |
| Resident contractor | continuous contract | months or years | lifecycle similar to employee |
| Construction crew | work front | construction phase | dynamic zones and schedules |
| Auditor or inspector | specific assignment | short period | specific areas |
| Delivery supplier | logistics | minutes or hours | defined route and dock |
Internal Sponsor and Authorization Authority
Without a defined relationship, validity period, and approver, third parties may retain access after the activity ends. Structuring requirements connects the contract, person, area, and work window before registration.
Every external identity must have an internal responsible party, contract manager, or sponsoring business unit. This actor justifies the need for access, validates the continuity of the relationship, and is accountable for changes that reception or the security team cannot infer on their own.
Without a sponsor, security ends up making business decisions: whether the person still needs to enter, whether the contract was extended, whether one technician replaced another, or whether the service requires access to a critical room. This creates informal decisions and weakens traceability.
The sponsor does not need to perform the registration, but must be identified in the workflow and linked to the authorization period and scope.
Contracts and work orders should limit access
When there is a contract, work order, project, or work front, the external identity must be linked to the instrument that justifies their presence. The end of that instrument is a strong termination event.
If the contract ends on a given date, it makes no sense to issue credentials with no validity period and depend on a future manual cleanup. In long-term contracts, credential validity may be shorter than the contract term and require periodic recertification. This is useful when people join and leave the supplier’s team without a formal change to the contract.
The system does not need to store the entire contractual document, but it must retain enough reference information to explain why the access exists and who is accountable for it.
Prerequisites Before Activation
Some environments require training, safety induction, technical authorization, operational registration, or other conditions. The EACS should not become the system of record for all these requirements, but it can consume a consolidated status such as “eligible” or “not eligible” from an appropriate source.
The design must avoid two extremes: allowing access before validation and indefinitely blocking someone because the integration that reports eligibility failed without generating an alert.
When a requirement has its own validity period, such as recurring training, access may be conditioned on the shortest period among the contract, authorization, and required qualification.
Registration, identity, and duplicate prevention
The registration process should avoid creating a new person every time the service provider returns. Consistent identifiers, deduplication rules, and history make it possible to recognize that the same person participated in different contracts over time.
Identity must remain separate from the relationship. The person is the same; company, contract, area, and period may change. This separation preserves history without reusing old privileges for convenience.
When biometrics are used, enrollment must remain subordinate to the current relationship. A template should not remain authorized simply because the person may return someday.
Validity should follow the actual relationship
Third parties are one of the populations for which automatic expiration provides the greatest benefit. Validity can be calculated from the shortest relevant period: contract, work order, training, area authorization, shift, or credential.
If the contract is extended, extending access should generate an event, approval, and history. Silently changing a date eliminates traceability.
It is also necessary to distinguish the contracted company’s term from the individual’s validity. The contract may remain active while a particular technician leaves the team. Individual authorization must follow the actual situation.
Least Privilege: Zones, Routes, and Schedules
Service providers should receive only the areas compatible with the service being performed. Generic profiles such as “THIRD PARTIES” tend to accumulate zones and exceptions over time.
A safer model uses profiles by role, location, project, or activity. Schedules should also follow operations. A night maintenance team may have no reason to circulate through administrative areas during business hours; a construction project may operate within its own time windows.
Authorization must be understandable to the approver. The manager should know which areas and schedules are associated with the profile, rather than merely recognizing an internal code.
Escort, dual authorization, and authentication
Some areas require accompaniment. The rule may be operational, system-based, or combined. In higher-criticality locations, it may be necessary to require two distinct identities, additional approval, or stronger authentication.
It is important to distinguish concepts: dual custody involves two people; multifactor authentication combines more than one factor for the same identity. These mechanisms address different risks and should not be treated as synonyms.
The design must document which condition is required for each area and how that condition will be tested.
Credential selection
Cards, QR Codes, mobile credentials, and biometrics can serve third-party populations, but the decision depends on duration, frequency, risk, infrastructure, and operating cost.
QR Codes may be appropriate for temporary access and pre-registration when validity is short and issuance is controlled. Physical cards work well for recurring teams, but require inventory, issuance, collection, and revocation. Mobile credentials reduce physical logistics, but create dependency on the device and provisioning process.
Biometrics may be proportionate in critical environments, but involve sensitive personal data and specific requirements for enrollment, retention, and deletion. The choice should arise from risk and process, not from the available technology.
Credential Sharing, Anti-Passback, and Tailgating
Third-party credentials may be shared when the process is slow, passage capacity is inadequate, or the operational culture tolerates shortcuts. Anti-passback helps prevent simple sequential reuse of the same credential, but it does not eliminate tailgating.
Physical barriers, flow design, passage capacity, awareness, and event investigation must work together.
If access is so slow that it creates queues incompatible with operations, unsafe behavior may be a consequence of the design itself. Throughput must be sized for the actual peak of external teams.
Vehicle, driver, and passenger are different entities
At industrial, logistics, and construction sites, the service provider may arrive in a personal or company vehicle. Vehicle authorization must not replace person authorization.
License plate, UHF tag, or LPR identifies the vehicle; the driver and passengers remain distinct identities. The process must decide whether an authorized vehicle may enter with a different driver and how to handle passengers, deliveries, and substitutions.
In more controlled environments, route, dock, parking location, and access window may be part of the policy.
Administration Delegated to the Supplier
Delegated administration spans the supplier, sponsor, and security team. An interface review identifies excessive permissions, team changes, and exceptions without closure before implementation.
Large contracts may allow the service provider itself to pre-register its team. This improves scalability, but should not transfer final access authority.
The supplier may provide data and request inclusion; the sponsor, security team, or corporate workflow must validate it. Delegated administration must have scope: one company should not be able to view another company’s data, change zones outside its responsibility, or extend validity beyond the contract without a new approval.
There must also be authorship logs and control over the supplier portal’s administrative accounts.
Changes to the company, contract, and work front
Changes in corporate name, subcontracting, team replacement, contract amendments, and scope changes may alter physical authorization. The system must distinguish the person from the company.
If the technician changes service providers, the old relationship must be terminated and the new one evaluated. Simply changing the company name in the record erases history. Likewise, a change in work front should recalculate zones and schedules.
Adding the new access without removing the old one creates accumulated privilege. The final state must be recalculated based on the new condition.
Third-Party Offboarding
Termination may be triggered by the end of the contract, removal from the team, contract termination, an incident, a sponsor decision, or expiration. For third parties, the challenge is identifying who generates this event, since internal HR may not know that the person has left.
Therefore, the sponsor, contract management function, or vendor management system must be the source of the termination event. The time between the event and effective revocation must be known and monitored.
Card collection is a complementary control; it does not replace revocation. If the credential medium is not returned, it must remain unusable.
Multi-site environments and mobility between facilities
Service-provider companies may work at multiple facilities. A global registration can reduce duplication, but authorization must remain site-specific.
The model must decide who can approve mobility, whether one facility can view another facility’s data, and how to prevent a local profile from unintentionally becoming enterprise-wide access.
Different sites may also use different technologies. Identity must remain consistent even if one facility uses cards and another uses biometrics or mobile credentials.
Integration with contract and identity management
In mature environments, contract events can feed the third-party identity system and, consequently, the EACS. APIs, webhooks, or middleware require traceability, duplicate handling, queues, and reconciliation.
The mistake to avoid is making the contract the only condition. A person may leave the team before the contract expires; individual access must be terminated without canceling the entire company.
The process must also distinguish company qualification, individual relationship, and physical privilege.
LGPD and Data Minimization
Third parties remain data subjects. The process should collect only what is necessary, protect the data, and define retention.
Identity documents, photographs, biometrics, company information, phone numbers, and access history should not be stored by habit. The policy must distinguish data required for security, data required for contract management, and data retained for operational or legal requirements.
Logs and evidence
An audit must be able to answer who the person is, which company and contract justified the access, who sponsored it, who approved it, which zones and schedules were authorized, which credential was issued, when access began and ended, what changes occurred, and when revocation became effective.
This requires administrative events, not only passage records.
Maturity indicators
| Indicator | What it reveals |
| Third parties with defined validity | time-bound governance discipline |
| Expired credentials still active | expiration or synchronization failure |
| Revocation time | exposure after termination |
| Service providers without a sponsor | incomplete governance |
| Exceptions with no end date | temporary access becoming permanent |
| Duplicate identities | registration problem |
| Terminated contracts with active people | offboarding failure |
| Credentials not returned | logistics; must be accompanied by revocation |
The metric must drive action. A small number of critical credentials outside the permitted period may be more relevant than an apparently good average rate.
Service Provider Onboarding Journey
Onboarding should begin before arrival at reception whenever volume or risk justifies it. When registration, validation, and authorization occur only at the physical entrance, the process creates queues and pressures operators to relax controls.
A structured journey may follow these steps:
- the company is qualified within the contract context;
- the sponsor communicates the need;
- the service provider registers or identifies personnel;
- prerequisites are verified;
- areas and schedules are approved;
- identity is validated;
- the credential is issued or provisioned;
- the first access confirms the state;
- changes and expiration become governed.
The required lead time depends on operations. One-time deliveries do not justify the same process as a resident team.
Risk Model by External Population
Not all third parties represent the same exposure. The design can classify risk using duration, frequency, area criticality, autonomy, after-hours access, and type of activity.
| Criterion | Low | Medium | High |
| Duration | hours | weeks | months or recurring |
| Area | public/administrative | restricted | critical |
| Supervision | constant | partial | autonomous |
| Schedule | business hours | extended | 24×7 |
| Activity | low criticality | technical | critical process |
| Exposure | low | sensitive | high impact |
The classification serves to justify differences in credentials, authentication, escort requirements, and review frequency. It does not need to become bureaucracy with no operational effect.
Subcontracting
Subcontractors add a layer of governance. The system must identify which prime contractor sponsors them and which instrument authorizes their presence.
Subcontracting should not allow the prime contractor to create unlimited people without control. Limits, approvals, validity, and auditing remain necessary.
When the contract requires prior approval of the subcontractor, the status of that approval must reach the process before activation.
Integration with occupational safety and training
In industrial environments, access may depend on safety induction, specific training, fitness, or activity permits. The EACS can consume a consolidated eligibility status, but it must know the source and validity of that information.
If training expires, the rule may suspend certain areas until renewal. This requires handling synchronization and integration failures.
The physical system should not replace the management of these requirements; it should consume only the result necessary to decide access.
Change of Work Front
Third parties frequently change activities within the same contract. A team that was working in an administrative area may move to an operational area.
This is a change event and must recalculate zones and schedules. Adding the new access without removing the old one creates accumulated privileges.
The process must treat a scope change as a state transition, not as a simple addition to the profile.
Emergency, evacuation, and accountability
Knowing which third parties are inside the site can support emergency response, but the EACS should not automatically be considered a perfect presence system.
Tailgating, emergency exits, and missed reads can create discrepancies. If operations intend to use access events for muster or accountability, the design must define the confidence level, interfaces, and contingencies.
An exact headcount should not be promised without an architecture specifically designed for that purpose.
Lockdown and third parties
During lockdown, rules for third parties may be more restrictive than those for internal teams. The design must determine how external credentials behave, how egress remains compatible with life safety, and who may authorize exceptions.
These rules must be tested before an incident. Improvising during an emergency is a sign of an incomplete requirement.
Reception and gatehouse capacity
Implementation must account for peaks in registration, returns, renewals, and shift changes. Service time includes checking authorization, validation, photo or biometric capture, issuance, and orientation.
During construction mobilizations, hundreds of people may need to start in the same week. A single registration station may be insufficient. Pre-registration, staggered windows, and additional stations may be required.
Sizing throughput is part of the design because excessive queues encourage operational shortcuts.
Third-Party Recertification
Long-term contracts require periodic review because the named personnel list may change even when the contract term does not.
Recertification should require the sponsor or contract manager to confirm who is still part of the team and which privileges remain necessary. People without confirmation may be suspended according to policy.
The frequency should reflect risk and turnover.
Incident response
If a third party is involved in an incident, the organization must be able to quickly suspend their authorization without destroying the history. Temporary suspension is different from permanent revocation.
The audit trail must remain available for correlation with other events. When a broad restriction is required, the system may also need to suspend an entire company or contract, with authorization and evidence of the impact.
Exception matrix
Exceptions are inevitable: emergency technician, after-hours entry, activity extension, unexpected replacement, or credential failure.
| Exception | Who approves | Duration | Compensating control |
| Emergency technician | on-call responsible party | a few hours | escort |
| Shift extension | area manager | until the activity ends | log and supervision |
| Credential failure | reception/security | one-time event | additional validation |
| Temporary critical access | area owner | defined window | stronger authentication or dual authorization |
The matrix prevents an “exception” from becoming an improvised decision by whoever happens to be at reception.
Design Requirements
The design may require population classification, a mandatory sponsor, association with company and contract, automatic validity, specific groups, zones, schedules, escort rules, multiple credentials, vehicle integration, exception expiration, administrative logs, offline operation, and recertification reports.
Requirements must be verifiable. Statements such as “the system shall control third parties” are insufficient because they do not define states, time limits, responsibilities, or contingency behavior.
FAT, SAT, and acceptance criteria
Acceptance must demonstrate that only the authorized team enters the intended areas and that expiration, replacement, and revocation work in the field. The test campaign must also include failures and exceptions.
The FAT should test company creation, person registration, approval, issuance, expiration, replacement, contract change, sponsor change, revocation, exception handling, and reporting.
During the SAT, the service provider should open only authorized points, during permitted hours, and the behavior of vehicles, passengers, and contingency modes should match the design.
| Requirement | Test | Evidence |
| Contract-based validity | end the validity date | automatic denial |
| Mandatory sponsor | attempt registration without sponsor | workflow rejection |
| Minimum zones | test unauthorized door | denial and log |
| Team change | remove person | revocation confirmed |
| Temporary exception | grant and expire | complete history |
| Delegated administration | attempt to exceed scope | operation denied |
| Offline | isolate controller | expected behavior |
Contracting and Deliverables
Contracting only readers and registration functions does not deliver third-party governance. The scope must define workflows, responsibilities, evidence, and acceptance criteria to sustain operations.
When the system will be procured or integrated by third parties, the scope must define minimum data, interfaces, licensing limits, retention, export, administrative security, audit capabilities, and testing criteria.
Recommended deliverables include a population matrix, sponsor workflow, registration requirements, validity rules, zone matrix, schedules, credential model, vehicle integration, exceptions, integration requirements, logs, reports, test cases, RACI, migration, and as-built documentation.
The procurement must specify the process and evidence, not just readers, cards, and software.
Assisted operation and large mobilizations
Construction projects and major maintenance shutdowns can have rapid population changes. During the first cycles, assisted operation helps identify registration bottlenecks, queue peaks, profile errors, poorly configured companies, and requirements that arrive too late.
The team should measure times and correct the process before operators create permanent workarounds.
Mass terminations must also be planned. The end of a construction phase or shutdown may require revoking hundreds of people in a short period. The system must support batch actions with control, evidence, and synchronization confirmation.
Audit and contract oversight
Reports can support oversight: active list by company, validity, exceptional access, people without sponsors, pending cards, and team changes.
These reports do not replace contract measurement, but they help verify whether mobilization adheres to the scope and site rules.
A risk-based sample audit can prioritize critical areas, suppliers with high turnover, newly mobilized contracts, rarely used credentials, and exceptions.
Mobilization Example: An Active Contract Does Not Mean an Authorized Team
Consider planned maintenance with twenty service providers, two shifts, and three areas. The contract remains valid for six months, but the first activity lasts five days. The authorization matrix should reflect the activity window and the required areas, rather than granting the entire team six months of unrestricted access. The contractor provides the named personnel list; the sponsor confirms the need; the area owners validate the permissions; and operations performs registration according to the approved workflow.
On the third day, one person is replaced and another changes work fronts. These are two different events: the first person no longer needs access; the second remains linked to the contract but now requires a different combination of areas and schedules. Simply adding names to the initial list creates orphaned credentials. Simply changing the company name does not terminate the previous relationship. The system must preserve authorship, justification, start, and end of each change.
At the end of the activity, the team compares the personnel actually mobilized with the remaining authorizations. Returned cards and revoked credentials are complementary checks. A collected credential medium may still be active in the system; an unreturned medium may be correctly blocked. The report must distinguish these situations, identify the devices that confirmed the update, and assign responsibility for any pending item.
The example shows why the process cannot depend exclusively on an annual supplier registration. Governance must follow the person, relationship, activity, area, and period. On projects with multiple work fronts, the work order may be the most useful authorization unit, provided it is treated as a design requirement rather than introduced informally at reception.
Verifiable Escort and Exceptional Access Without Permanent Privilege
When accompaniment is mandatory, the design must indicate what proves the escort. A name recorded in an observation field does not demonstrate that the escort was actually present. Possible controls include operational validation at reception, association between the visitor and the responsible person, dual presentation of credentials at a compatible access point, or another documented procedure. The choice depends on risk and technology, and the article on dual custody further explains the difference between requiring two identities and simple accompaniment.
Emergency technician access requires its own workflow: reason, available approver, verified identity, minimum scope, time window, and evidence. The system should not turn an emergency service provider into a permanent member of a maintenance group. The end of the window must also be handled: preventing new entries must not create an undue obstacle to safe egress. Entry authorization and evacuation must remain compatible with the facility design.
The test campaign must verify access without an escort when one is required, an escort whose authorization has expired, an attempt outside the permitted area, an extension without approval, and early removal from the team. Negative cases are as important as permitted entry. Acceptance must demonstrate that the process rejects improper combinations and provides an operationally understandable response for legitimate situations that require analysis.
How to Measure the Service and Transfer Management to Operations
Implementation can be measured through verifiable deliverables: characterized population, approved authorization matrix, configured workflow, completed acceptance-test cases, field verification, and received documentation. The number of registrations performed does not, by itself, demonstrate that the rules are correct. The contract must define who approves the profiles, who executes changes, and who validates that the configuration corresponds to the requirement.
Technical support for oversight can track changes during mobilization and verify that testing remains aligned with the scope. When a failure appears, the pending item must identify the affected rule, exposed population, temporary treatment, and retest. Classification must distinguish a report presentation error from a condition that grants improper access to a critical area. Payment or acceptance of each milestone must follow the criteria actually established in the contract.
At handover, reception must receive procedures for registration, replacement, expiration, incidents, and outages. Managers must know how to review lists and approve exceptions; IT must understand integrations and recovery; security must govern profiles and evidence. The technical handover framework organizes this transfer so that the process continues to operate after the implementation team is demobilized.
The eBook on enabling digital security projects complements the discussion of procurement and delivery models, but does not replace access requirements, testing, or risk approval. Distinguishing planning material, technical specifications, and field evidence helps the reader procure the appropriate service. The value of the design lies in making each authorization decision understandable, executable, and auditable.
Final Considerations
Access control for third parties should not be a parallel, less-governed registration process. Because the external relationship is temporary and distributed across companies, contracts, and sponsors, it requires explicit validity, least privilege, change and expiration rules, and evidence.
A mature architecture can answer who authorized the access, under which contract, in which areas, during which period, with which credential, and when revocation became effective. This reduces orphaned access, generic profiles, and reliance on operational memory.
Technical references
[1] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 60839-11-1:2013 — Alarm and electronic security systems — Part 11-1: Electronic access control systems — System and components requirements. Available at: https://webstore.iec.ch/en/publication/3662
[2] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST SP 800-116 Rev. 1 — Guidelines for the Use of PIV Credentials in Facility Access. Available at: https://csrc.nist.gov/pubs/sp/800/116/r1/final
[3] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems and Organizations. Available at: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
[4] ISO. ISO/IEC 27002:2022 — Information security, cybersecurity and privacy protection — Information security controls. Available at: https://www.iso.org/standard/75652.html
[5] BRASIL. Lei nº 13.709/2018 — Lei Geral de Proteção de Dados Pessoais. Available at: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm
[6] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR IEC 60839-11-2:2019: Sistemas de segurança eletrônica e alarme — Sistemas eletrônicos de controle de acesso — Diretrizes de aplicação. Seções 7.3, 9 e 11. Available at: https://www.abntcatalogo.com.br/
Frequently asked questions
Not always. Recurring service providers have a relationship, contract, time limits, and operational needs that normally require a more structured lifecycle than a one-time visit.
It can be shorter. Limited validity or periodic recertification is common even for long-term contracts, especially when the supplier’s team changes frequently.
No. The credential must be revoked in the system; physical collection is a complementary control.
Vehicle authorization must be separate from the identity of the driver and passengers, with specific rules for license plate, tag, or LPR.
Normally an internal sponsor or formally designated contract owner, combined with security rules and the requirements of critical areas.
With scenarios covering registration, approval, validity, zones, schedules, team changes, exceptions, revocation, offline operation, and verification at the physical access point.
Complementary technical materials
Related services
- Engineering Needs and Requirements Program: demands, performance, and design criteria
- Design Review for Engineering Projects: technical review, interfaces, and design maturity
- Access Control Design: architecture, devices, integration, and specification
- Technical Planning for Engineering Procurement: strategy, requirements, risks, and documentation
- Technical Support for Engineering Works and Contract Oversight: control, evidence, and compliance
- Equipment Commissioning: FAT, installation, SAT, startup, and acceptance
Main content on the topic
- Access Control System: types, technologies, standards, and design
- Visitor management integrated with access control: registration, authorization, LGPD, and operations
- Credential lifecycle in access control: issuance, modification, revocation, expiration, and auditing
- Tailgating and anti-tailgating in access control: risks, detection, and design criteria
- Dual custody in access control: two-person rule, dual access, and dual occupancy
- Commissioning access control systems in accordance with IEC 60839
