Physical penetration testing vs red teaming

When to commission a physical penetration test and when to commission a red team

A regulated organization that wants to know whether its doors, badges and reception desk hold up should commission a scoped physical penetration test when the question is about the facility itself. A red team fits when the question is whether an adversary can reach a business objective, and physical access is only one of several routes. The two overlap, so the decision turns on what the board needs to learn and which controls it needs to prove. Choose a scoped physical test when the risk sits in specific access points: data centers, server rooms, card-controlled doors, visitor management and tailgating at staff entrances. NIST SP 800-53 Rev. 5 control enhancement CA-8(3), Facility Penetration Testing, describes a test that attempts to bypass or circumvent controls at physical access points, and NIST notes it can reveal weaknesses in the physical controls protecting systems. Note that CA-8(3) is not selected in any SP 800-53B baseline, so a regulator or contract may still require the test even if your baseline does not. Confirm that requirement with the authority or client before you scope the work.

Choose a red team when you want to know whether an attacker could combine a phone pretext, a badge clone and a network foothold to reach a crown-jewel system. NIST's guidance on CA-8 covers red team exercises, and its guidance on CA-8(2) notes that social engineering in those exercises can include email, telephone, shoulder surfing and personal conversations. Physical access in that setting is a means to an objective, so the rules of engagement, authorization letters and escalation contacts must cover every channel the team may use. Combine both when the facility is one of several paths: run the physical test first to fix known control gaps, then let the red team test whether the remaining defenses stop an attacker who uses them. Ask providers to state in writing which findings will be reported to the board and how any staff-facing social engineering will be stopped if a real emergency occurs.

Physical penetration testing and red teaming side by side

This table compares a scoped physical penetration test with a red team that uses physical access as one route to an objective. Read each row as a question to answer in your scoping document, and treat the conditions in each cell as the points to confirm with the provider before work starts.

Dimension	Physical penetration test	Red team with physical access
Primary goal	Find weaknesses in locks, badge readers, reception, visitor handling and tailgating defenses at defined sites	Reach a stated business objective, such as a system or data set, where physical entry is one path among several
Scope	Named facilities, doors and access points, listed in advance	Objective and target boundaries set by the client, with physical, digital and social routes allowed inside them
Rules of engagement	Written limits on tools, hours, lock-picking, badge cloning and who may be approached. NIST SP 800-115 provides a template in Appendix B	Same written rules plus escalation contacts, stop conditions and limits on deception, pretexts and impersonation
Method	Tests access controls directly, including attempts to bypass or circumvent controls at physical access points, as described in NIST CA-8(3)	Chains techniques over time, which can include social engineering by email, phone, shoulder surfing or conversation as described in NIST CA-8(2)
Testers	Staff with physical security and social engineering skills, often under a team lead who holds the authorization letter	Team with operational experience across physical, social and technical work, and a designated control cell on the client side
Legal authorization	Signed letter naming the sites, dates and authorized staff. Confirm whether the team may enter occupied premises, use fake credentials or contact landlords	Signed letter covering all in-scope routes, plus a named contact who can stop the test and confirm it to police or building security if needed
Reporting	Site-by-site findings with evidence such as photos or access logs, and fixes for each control weakness	Narrative of the attack path, the objective reached or not, detection points and joint review with defenders
Relation to NIST CA-8	Maps most directly to CA-8(3) facility penetration testing, which is not selected in any SP 800-53B baseline	Maps to CA-8(2) red team exercises, which are selected only in the high baseline per SP 800-53B Release 5.2.0
Who needs it	Operators of data centers, labs or branches that hold regulated data and want their physical controls tested on their own terms	Organizations that want to test whether a physical breach would lead to a damaging outcome, and whether defenders notice it

What each approach finds and misses

Physical penetration testing and red teaming overlap on the same doors, badges and reception desks, but they answer different questions. The cards below show what each approach tends to surface, the condition under which that matters, and the gaps neither one closes on its own.

Physical controls under direct test

A scoped physical test tries locks, badge readers, mantraps, camera coverage and door sensors one at a time, looking for bypasses such as tailgated entries, propped doors or readers that accept cloned credentials. This matters most for data centers, lab space and server rooms where the physical control is the last barrier. NIST CA-8(3) frames this as attempts to bypass or circumvent controls at physical access points. Ask the tester which controls are in scope and whether bypass attempts will be documented per door.

Reception and tailgating behavior

Tailgating and reception checks measure whether staff challenge an unknown visitor, verify a badge or escort a guest. These results depend heavily on the building's daily rhythm, so a test run at a quiet hour can overstate or understate exposure. The condition that makes this matter is an office with shared entrances or contractor traffic. Confirm with the provider whether tests are run during business hours and whether staff are debriefed without being named in the report.

Staff response to pretexts

Pretexting checks whether an employee releases information or access to someone posing as a vendor, auditor or new hire. NIST SP 800-115 lists posing as a help desk agent to obtain passwords as a validation technique. Results matter most where help desks reset credentials or where facilities staff grant building access by phone. Confirm the pretext scripts are agreed in advance, that no personal data is collected beyond what the finding needs, and that the legal authorization letter names the people permitted to act.

Chained attacks from physical to network access

A red team may use a tailgated entry to reach an unlocked network jack or to plant a device, then pivot inward toward the stated objective. This chain is the only place where the two approaches clearly diverge, because a standalone physical test usually stops at the door. The chain matters when the objective is data or system compromise rather than facility entry. Ask whether the rules of engagement allow implanted devices and where the boundary of the test sits on the network.

Gaps neither approach closes

Neither a physical test nor a red team engagement measures long-term insider behavior, such as an employee who misuses access over months, nor the quality of detection unless monitoring is part of the scope. A single engagement shows what happened on test days. If the goal includes whether guards, cameras and the SOC notice and respond, add a measured detection check, and consider threat hunting for insiders who are already present.

Which social engineering methods belong in each test

Social engineering appears in both kinds of engagement, but the method list should differ by test. A scoped physical penetration test usually centers on tailgating, badge cloning attempts, reception pretexts and questions about entry procedures, because those are the controls it is meant to exercise. A red team may add phone pretexts, impersonation of a help desk agent or a vendor, and email lures, since its objective can be reached through a person as easily as through a door. NIST SP 800-53 Rev. 5 control AT-2(3) lists tailgating and pretexting among the social engineering forms that awareness training should cover, which is a useful checklist for deciding what staff have been taught to recognize. NIST SP 800-115 gives posing as a help desk agent to request passwords as an example of social engineering used for target validation.

Each method needs its own scope line in the rules of engagement, which NIST SP 800-115 provides as a template in Appendix B. Name the permitted pretexts, the people or roles that may be contacted, the locations and the hours, and the actions testers may not take, such as obtaining credentials that they then use beyond the agreed objective. Confirm with the client who may authorize each activity. A signed authorization letter should name the individuals who will attempt the method and the sites covered, so that a guard or employee who challenges a tester can verify the work is sanctioned. Ask the provider how it handles personal data collected during a pretext and whether any calls or recordings are retained.

Record evidence in a form that supports both the fix and the legal file: the time, location, method, who was approached, what was disclosed or granted, and whether a report was made. Do not treat a count of successful attempts as a measure of the program, and do not ask a provider to promise a result. Ask the provider how it records failed attempts as well as successful ones, because the absence of a finding is only meaningful if the attempts were documented. Finally, agree in advance who receives the findings. Reception and facilities staff, help desk leads and HR may each need a different, limited view of the outcome.

How to scope a physical test or red team in order

This sequence turns a vague wish to test physical security into a written, authorized exercise with named owners, clear boundaries, and a plan for how findings get confirmed and fixed.

Define the objective and risk owner
The buyer states what the exercise must answer, such as whether badge controls hold at a data center or whether an intruder could reach a server room, and names one executive who accepts the residual risk. Scope a facility-only test against a red team that uses physical access as one path to a goal, because the two need different rules. The step is done when the objective and owner are written in one page that the provider and legal team both sign. Ask the provider how it will tie its test to that objective.
Decide facilities and systems in scope
List every building, floor, entrance, loading dock, and room the test may touch, plus the systems that sit behind them. Note third-party sites such as leased space, colocation halls, or branch offices, because the owner of each site must consent before testing begins. NIST SP 800-53 control enhancement CA-8(3) describes facility penetration testing that attempts to bypass controls at physical access points, so confirm whether your scope matches that intent. The step closes when an in-scope and out-of-scope list is approved. Ask the provider how it handles surprises, such as a site it discovers during reconnaissance.
Agree rules of engagement and authorization
Document the permitted techniques, including tailgating, lock picking, badge cloning, pretexting by phone or email, and any limits on force or damage. Set rules for what happens if testers are detained, when they must stop, and who the emergency contacts are. NIST SP 800-115 provides a rules of engagement template in Appendix B that can serve as a starting point. Obtain a signed authorization letter that names the testers, dates, sites, and the executive who authorizes the work, and that the testers carry during the test. The step is done when legal, the risk owner, and the provider have signed both documents. Confirm with counsel which local laws govern entry, recording, and impersonation in each location.
Set a deconfliction process
Name a small group of trusted contacts who know the exercise is underway, usually security leadership and one facilities or site contact, and give them a secure way to confirm or stop activity. Agree a code phrase or verification step that testers use if they need to be recognized during a live test. Decide how the security operations team and reception staff will be handled so they do not treat a live exercise as a real incident, while still being measured on what they do. The step is complete when the deconfliction plan is written, tested by a call or message check, and the contact list is kept current. Ask the provider how it records each deconfliction contact in its logs.
Run the test within the agreed boundaries
The provider performs reconnaissance, then attempts entry, access to restricted areas, and movement to the objective, following the rules of engagement. Testers log each attempt with time, location, method, and outcome, and the deconfliction contacts monitor for safety issues. Stop the test immediately if a safety or legal concern arises, and record the reason. The step closes when testing ends and the provider delivers a timeline of attempts, including those that failed. Ask the provider what evidence it captures, how it stores photos or footage, and how that material is destroyed after reporting.
Validate and report findings
The provider writes findings with the path used, the control that failed or held, and the evidence supporting each claim. Your team checks each finding against the logs and confirms it reproduces where safe to do so, so that one-off oddities are not treated as systemic gaps. Agree severity labels and how physical findings will be grouped with related logical or process findings. The step is done when a validated findings list is accepted by the risk owner. Ask the provider how it distinguishes confirmed weaknesses from observations.
Agree fixes and retest
Assign an owner and a target date for each accepted finding, and decide which fixes require facilities work, policy updates, or staff retraining. Plan a retest of the specific paths that failed, with the same deconfliction and authorization steps applied again. Record the retest result against the original finding so that closure is provable to auditors or executives. The step is complete when each finding has a status of fixed, accepted, or in progress, and the retest scope is signed. Confirm with the provider whether retesting is included in the fixed-scope quote or priced separately.

Which buyers need each approach

Operators of data centers, power, water, or other critical facilities have the strongest case for a scoped physical penetration test. Their adversaries may gain value from getting inside the building itself, so the test should check locks, badge readers, mantraps, reception, and tailgating defenses against the facility's own risk statement. NIST SP 800-53 Rev. 5 control enhancement CA-8(3) describes facility penetration testing as an attempt to bypass controls at physical access points, and its guidance says such testing can reveal weaknesses in the physical controls that protect systems. Because CA-8(3) is not selected in any SP 800-53B baseline, a facility test is a choice that the organization makes from its own risk assessment rather than a baseline requirement.

Scope the facility, not the brand: Define which sites, rooms, and access points are in scope, including colocation halls and shared loading docks.
Test the controls that protect the systems: Cabinets, cages, cooling, and power rooms are the targets that matter most.
Plan for tailgating and pretexting: Ask whether the team may use posed staff, delivery tickets, or contractor badges.
Require written authorization: Confirm who signs the letter, who can stop the test, and how police or landlords are informed.
Check contractual obligations: Colocation agreements may limit who can enter and how.

Before buying, confirm with your facilities and risk teams whether a physical test is already part of your risk register and how often it should recur.

What you receive from each engagement

This table compares what a scoped physical penetration test and a red team engagement hand back to the client, row by row. Read it to judge whether you will get a bounded list of physical control weaknesses or an attack narrative that shows how physical access fed into a wider objective. Confirm exact contents in each written scope, because deliverable sets vary by provider.

Deliverable	Physical penetration test	Red team engagement
Scoping documents	Defines the facility, access points, hours and techniques in scope, such as locks, badge readers, reception and tailgating	Defines the objective, threat scenario, permitted physical and digital paths, and any excluded systems or people
Authorization letter	Signed letter naming the testers and the sites, so staff and guards can confirm the activity is sanctioned if challenged	Signed letter covering the full campaign, including any physical entry, social engineering contacts and named escalation contacts
Evidence log	Timestamped record of each attempt, what was bypassed, and photos or notes kept under the agreed handling rules	Timestamped record of every step across physical and digital activity, used to rebuild the attack path afterward
Findings with physical control recommendations	Ranked list of weak locks, badge controls, visitor processes or staff behaviors, each with a fix such as a control change or procedure update	Findings tied to the objective, with physical weaknesses listed only where they enabled a step in the chain
Attack narrative	Usually not the main output; a short account of each entry method is included	Core output: a readable account of how the team moved from first access to the objective, including choices made along the way
Timeline of events	Sequence of attempts and outcomes, useful for mapping when guards, cameras or staff responded	Full timeline across the campaign, including when defenders noticed, escalated or ignored activity
Detection observations	Records whether staff, guards or cameras noticed an attempt, and what they did	Records what the blue team detected, missed or responded to, which the joint review uses to tune monitoring
Retest report	Confirms whether each physical fix holds, if a retest is contracted in writing	Confirms whether the attack path is closed after remediation, if a retest is contracted in writing
Executive summary and joint review	Summarizes exposure for facilities and risk owners; no pass or fail verdict is implied	Summarizes the objective and path for leadership; under TIBER-EU style exercises, no pass or fail result is produced and the output is a joint review with defenders

What drives cost and effort for each approach

Physical penetration testing and red teaming both price on the same underlying inputs: how much ground is covered, how long the testers are on it, and how much preparation and paperwork surround the work. The cards below show which drivers move the quote and what to ask for in writing before work starts, since a quote follows from the agreed scope.

Number and type of sites

Each building, data center room, branch or remote site adds travel, setup and reporting. A facility-level test of one office is a different job from a test across a campus, a data center and several branches. A red team may also need to cover sites where it never enters but where staff, vendors or badges connect to the target. Ask the provider to list every site by name, type and address in the scope, and to state whether each site is in scope for entry attempts, observation only or both.

Access points and operating hours

Doors, gates, turnstiles, badge readers, loading docks and visitor desks each need test time, and some need several attempts at different hours. Testing during shift changes, after hours or at weekends often changes the effort and the staff involvement needed. Ask how many access points are in scope, which hours are covered, and whether the test window includes the periods when guards and receptionists are most likely to be active.

Objective breadth

A test that only checks whether testers can pass a reception desk is narrow. A red team with an objective such as reaching a server room, copying a document or placing a device on a network segment has more paths to evaluate and more steps to document. The more objectives and the more paths allowed, the more time and reporting the quote carries. Ask which objectives are fixed, how many paths are in scope, and what happens if testers reach an objective early.

Pretext development and staff involvement

Convincing pretexts, such as a contractor with a valid-looking work order, take research into names, vendors and internal processes. Some testing also needs a small group of client staff who know the test is running, such as a sponsor, a facilities contact or a safety officer. Pretext research is usually billed as effort, and staff time is a cost your organization carries internally. Ask who builds the pretexts, what open-source research is included and how many client contacts must be briefed.

Legal, permit and authorization work

Physical entry requires signed authorization letters that name the sites, dates, people and actions permitted, plus emergency contacts for stopping the test. Some premises, such as leased buildings, shared campuses or regulated facilities, need landlord, facility or regulator notice. Ask who prepares and reviews the authorization letter, which local rules apply, and whether the provider's counsel or yours must sign off before testing begins.

Reporting depth and retesting

A short findings list is cheaper than a report that documents each entry attempt, the controls bypassed, photographs (where allowed), the root cause and the fix. Retesting after remediation is a separate line in most quotes and recurs whenever a control changes. Ask what the report must contain, whether it will feed a risk register or a remediation tracker, and whether one retest round is included or priced separately.

Questions buyers ask before hiring physical testing or red team help

Can a physical penetration test run on its own without a red team?

Yes. A physical test can be scoped only to facility access points such as doors, badge readers, reception desks and loading bays, with the objective of checking whether those controls can be bypassed or circumvented. NIST's guidance for control enhancement CA-8(3) describes exactly this kind of facility penetration testing, and it is a separate enhancement from the red team enhancement CA-8(2). The scope decides the format: a physical-only test answers whether the building controls hold, while a red team answers whether an adversary can reach a business objective. Confirm with the provider which of these you are buying, because the deliverables and authorization letter differ.

Does a red team engagement have to include physical access?

No. Physical access is one possible path, not a requirement. NIST's guidance for CA-8(2) says social engineering in red team exercises can include email, telephone, shoulder surfing or personal conversation, and it does not make a site visit mandatory. Whether physical access belongs in the rules of engagement depends on the objective, the threat model and what the client is willing to have tested on premises. Ask the provider to explain how physical attempts would be authorized, limited and stopped, and who on your side can halt them if a real person is involved.

What does the work need from our staff?

Expect a named sponsor, a small set of people who know the facility and its security contacts, and someone who can approve the rules of engagement in writing. NIST SP 800-115 includes a rules of engagement template in Appendix B, which is a useful starting point for defining testing windows, permitted techniques, escalation contacts and out-of-scope areas. For physical work, you also need to decide which guards, facilities staff and building management will know the test is happening, since that knowledge changes what the test measures. Ask the provider how they will handle a tester being challenged or detained, and who is notified.

How long does preparation take and what drives it?

The main drivers are the number of sites, how many access points and control types are in scope, how much intelligence the provider must gather before testing, and how fast your legal and facilities reviews move. A red team adds planning for the objective, the threat intelligence inputs and the deconfliction steps, and TIBER-EU's framework, for example, describes preparation as its own phase before any active testing begins. No duration is given here because it depends entirely on your environment. Ask the provider to break preparation into written steps with owners, so you can see which parts depend on your staff.

Can we run physical or red team tests ourselves?

You can run some of the work internally, such as reviewing badge logs, checking door hardware and rehearsing guard response, but an independent test needs a tester who is outside the team that runs the controls. NIST SP 800-53 CA-8 describes an independent penetration testing agent or team, and the PCI SSC's penetration testing guidance is clear that running an automated tool does not satisfy a penetration test requirement. Internal staff can be useful for purple team style exercises where defenders and testers work together. Confirm with your assessor or regulator whether internal testing counts toward the control you need to evidence.

How should we ask providers for a quote?

Ask for a written scope before a price, because the scope drives the cost. The request should name the facilities or sites, the access points in scope, whether social engineering by phone or email is included, the objective for any red team, the reporting format and the retesting approach. Ask the provider to state what is one-time (planning, testing, reporting) and what recurs (retests, annual repeats, updated threat intelligence), and to list who is paid for what, including any subcontracted testers. DeployOpen plans and delivers most engagements as fixed-scope work, with the scope, deliverables and timeline agreed in writing before work starts, and it does not publish a price list, so a quote follows from that written scope.

How do results feed into control fixes?

Good results name the control that failed, the path the tester used and the evidence, then map each finding to a fix with an owner. NIST's guidance on CA-8(3) says facility penetration testing helps correct weaknesses in the physical controls that protect systems, so findings should flow to facilities, security operations and access management alike. CIS Safeguard 18.4 asks organizations to validate detections after each test, which means checking whether monitoring and guards noticed the techniques that worked. Ask for a debrief, a prioritized remediation list and a retest plan so you can confirm that fixes changed the outcome rather than just the paperwork.

How physical testing and red teaming work together

A scoped physical test and a red team exercise answer different questions, but the output of the first can feed the second. Physical findings become red team scenarios when a tester shows that a badge reader can be cloned, a reception desk can be bypassed or a tailgate succeeds at a particular door. Each of those results tells the red team which access path works, which mitigates the attack and which staff routines the attacker can exploit. The red team can then start from an established foothold or a validated entry route instead of spending its time on the same ground. NIST SP 800-115 supports this kind of layering: it notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, and it treats social engineering as one of several target validation techniques rather than a standalone exercise.

Before combining the two, agree on the handoff in the rules of engagement. NIST SP 800-115 provides a rules of engagement template in Appendix B that you can adapt. Record which physical findings are in scope for reuse, who approves a red team that walks through a door a physical tester already opened, and how the red team records a finding it did not need to repeat. A red team can reuse a physical finding by citing its evidence and date rather than repeating the test. Confirm with your provider that the physical report is written in a form the red team can cite, and that the authorization letter covers both activities, since a physical entry that falls outside the signed scope creates legal exposure for the testers.

Close the loop with monitoring. CIS Safeguard 18.4 asks that security measures be validated after each test so that detections cover the techniques the testers used. For a physical test, that means checking whether badge logs, door-held alarms, camera footage and reception sign-in records captured the activity, and whether the security team responded. For a combined exercise, it means checking the same for the red team's technical steps that followed. Ask your provider which detections it expects to see, how it will confirm them, and whether it will rerun the relevant steps after your fixes. The aim is a fix that is verified, not simply reported.

How DeployOpen scopes, delivers and supports security testing

DeployOpen plans and runs security testing inside the client's own infrastructure, and documents the work so the client can decide which exercise fits its risk. Physical and red team work are scoped in writing before any testing starts, so the authorization, objectives and boundaries are clear to everyone involved.

How we scope

Written scope agrees which doors, badge readers, reception points and tailgating scenarios are in or out of bounds.
Rules of engagement and a signed authorization letter set the legal basis, contacts and stop conditions before any entry attempt.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.

How we build

Test plans map physical access attempts to the control objectives the client wants checked, such as facility access controls.
Red team objectives are set in advance, and physical access is included only where the client wants it as one possible path.
Pretext materials, tooling and communications are reviewed against the agreed legal and safety limits before testing begins.

How we hand over

Reports record each attempt, what was bypassed or stopped, and the evidence collected, in a form the client can act on.
Findings are tied to the controls tested, so remediation owners can see which physical or process fix addresses each gap.
Handover covers the authorization record, evidence handling and a debrief with the client's security and facilities leads.

How we support

Ongoing support, upgrades and continuous testing are available as retainers for clients who test on a recurring cycle.
Retesting after remediation can be scoped as a follow-on piece of work, with its own written scope.
Clients confirm with DeployOpen which compliance evidence the engagement produces, since DeployOpen prepares evidence but does not issue audit reports or certifications.