Physical access control companies access points are where intent meets reality. A badge reader outside a loading dock, a keyed lever on a lab door, a turnstile at an office entrance, a camera that “should” see everything. Threat modeling these points feels different from modeling servers and networks, because the adversary can use weather, time, human behavior, and mechanical weaknesses that do not show up in software inventories.
A good physical access threat model is not a document you file away. It is a working mental model your team can use to make trade-offs: where to spend local access control company money, what to test, what to monitor, and what to accept as risk because the cost to eliminate it is unreasonable.
Below is an approach I’ve used on real environments, from small facilities with manual keys to multi-building campuses with access control systems, CCTV, and security staff. It is detailed enough to be practical, but flexible enough to fit your constraints.
Start with boundaries that actually match the building
If you start by modeling “the whole organization,” you’ll drown in scope creep. Physical access points should be modeled as a set of assets and pathways that a person can use to get from “outside” to “inside the environment that matters.”
That means you first decide what you are protecting, then define the relevant access paths. Your boundaries usually include:
- The physical perimeter or entry points, including ground-level doors, dock doors, gates, roof hatches, and any garage or vehicle entry. The internal transitions between zones, like office areas, data rooms, production spaces, labs, and restricted corridors. The systems that govern access decisions, like badge readers, locks, controllers, credential management, and alarm monitoring. The people and processes that sit between the hardware and the outcome, like visitor check-in, contractor escort policies, key issuance, and badge revocation.
A small but common mistake is to focus only on the door and ignore the workflow around it. I have seen a technically strong door with a weak credential process, where a temporary badge was never revoked after a contractor’s work ended. The “threat” was not the lock cylinder, it was the mismatch between access rights and operational reality.
Define threat scenarios in plain language
Physical threats are best modeled as scenarios you can visualize, not abstract categories. For each physical access point, ask how an adversary would attempt entry, what they would need, and what would stop them.
A scenario typically has these components:
The starting position (outside the building, in a parking area, in a lobby, in a hallway with legitimate access). The method (social engineering, tailgating, brute force, manipulation of alarms, credential theft, environmental exploitation). The target (a specific room, a control panel, a data center corridor, an asset that only exists behind that door). The system response (lock fails, alarm triggers, guard dispatch, recording, time delay, fail-open behavior). The attacker’s continuation (if stopped, can they adapt? If not stopped, what next step becomes possible).Scenario writing forces clarity. “Someone breaks in” is not useful. “An adversary photographs credential holders at the entrance and reproduces badges before access revocation propagates” is more concrete. Even if you cannot predict the exact method, you can evaluate the defense against the category of behavior.
Build an asset map that reflects movement, not just locations
Asset maps for physical security often become floor plans with a list of doors. That is necessary, but not sufficient. Movement is the real story. You want to know where a person can go once they bypass one control, and what controls they will encounter next.
I usually create three layered views:
- A door and access point inventory: every reader, lock, gate, mantrap, and any “informal” access route like a rarely used side door. A zone model: what areas are significantly different in terms of risk, and what privileges or capabilities they confer. A control dependency model: what fails if a component fails, and what still works.
The dependency model is where you discover hidden fragility. For example, a “fail secure” lock might depend on a power supply that is shared with unrelated circuits. If that circuit is down for maintenance, your “secure” behavior flips or alarms become unreliable. Similarly, a door might be monitored only by a camera, and if the camera is offline you have a blind spot even though the lock still functions.
Identify adversary capabilities and constraints without pretending you know everything
Threat modeling is not crystal ball gazing. It’s about bounding what could happen and designing for credible variation. For physical access, adversaries tend to differ in capability more than in ideology.
You can treat adversaries as capability bands. The key is to ground each band in what is plausible for your environment:
- An opportunistic intruder: someone seeking an easy entry with minimal planning, likely targeting weakest doors or least monitored entrances. A credentialed insider or near-insider: someone who can obtain legitimate-looking badges or has access during normal operations. A focused attacker: someone who rehearses routes, studies schedules, or uses tools to exploit mechanical weaknesses. A determined adversary: someone prepared to cause disruption, possibly with technical manipulation or sustained attempts.
You do not need to claim an exact probability for each band. You do need to ensure your defenses handle the constraints each band imposes. Opportunists fail quickly when you make “easy entry” hard. Determined attackers require resilience: layered defenses, recovery steps, and detection that holds even during partial failures.
One edge case worth thinking about is the insider threat. In physical environments, insider risk often shows up as process gaps rather than direct sabotage. People reuse old badges, they “borrow” someone’s badge to let a friend through, or they bypass an alarm procedure because they are late for a shift. Threat modeling should include those human patterns, not just lock-busting.
Analyze control effectiveness by failure mode, not by marketing language
Access control technology is full of confident wording: fail-safe, fail-secure, secure by design, tamper-resistant. Those phrases can be true and still miss what matters.
For each physical access point, evaluate controls across failure modes and misuse cases:
- Power or network loss: does the door fail open, fail locked, or become unpredictable? Credential failure: what happens when a badge does not read, is expired, or belongs to someone who should not have access? Alarm and monitoring failure: are alarms visible to the right people fast enough, and do they have a reliable escalation path? Maintenance mode: do techs get temporary access that later becomes permanent by accident? Tailgating and human factors: if the lock reads correctly, can someone still enter because enforcement is weak?
A practical technique is to write down, for each access point, what “good response” looks like within a defined time window. If an alarm triggers, who sees it, how quickly can they respond, and what is the expected outcome? If the response is “someone might notice later,” you should treat that as a different level of defense than “alerts page a duty guard immediately.”
I once worked with a site where badge readers were accurate, but alarms were routed to an email inbox that staff checked once per shift. The lock was never the problem. The monitoring workflow made it effectively optional.
Map detection to actions, because detection without response is theater
Threat models often list cameras, sensors, and alarms as controls. That’s only half the job. Detection becomes meaningful when it maps to action: deny entry, summon response, or trigger containment.
Consider the chain of custody for a physical incident:
- Does the system record evidence reliably when something happens? Is there a time synchronization between controllers and cameras, so events line up? Are there procedures for immediate response, and are they trained? Can the responder identify the affected door and the responsible individuals quickly?
Evidence matters too. If your cameras capture faces only when people stand centered, but an adversary knows how to avoid the frame, your practical detection capability is less than what the camera spec promises. That’s why threat modeling should consider adversary adaptation. If they can observe which entrance has coverage, they will target the coverage gaps.
Consider non-obvious access points and “adjacent” weaknesses
Physical access is rarely limited to doorways. People use logistics and utilities to move around controls. Utility corridors, electrical cabinets, ventilation access, and maintenance access can provide paths that bypass intended controls.
Common blind spots include:
- Loading areas with open windows, dock plates, or convenient blind spots around roll-up doors. Stairwells with doors that are “managed” by office staff, not security, and might be propped open. Server room air-return paths or ceiling spaces if they connect to restricted zones. Mechanical key access: spare keys stored in insecure locations, or shared key cabinets without auditable control.
You also need to think about “credential adjacency.” If contractors receive temporary badges for one site wing, do they have a pathway into another wing due to shared corridors or poorly configured access groups? A reader that is correctly configured for one door may still enable access if the attacker can gain entry elsewhere.
I like to run a structured walk-through with three lenses: where can an adversary physically stand to avoid recognition, where can they move if a door is opened, and where is access granted indirectly through shared infrastructure.
Score risk with consistency, then validate with real tests
Risk scoring can be a useful communication tool if it stays consistent. But physical security needs more than a single number. A consistent method is better than a perfectly calibrated one.
A workable approach is to score each scenario against:
- Feasibility: how easily a person could attempt it given typical access, tools, and time. Impact: what harm follows if it succeeds, and how far the attacker can progress. Detectability and response: how likely it is that the incident is noticed promptly and acted upon.
Once you generate scenario scores, validate them. Validation is where threat modeling becomes real engineering, not theory.
Validation methods should match your environment. Options include controlled drills, tabletop exercises with the people who would respond, and targeted tests of specific failure modes. I avoid “break it until it fails” testing without authority, but I do encourage safe, permissioned experiments.
For example, if tailgating is a concern, do an observation period on peak entry times and measure how often doors stay open or how often people bypass procedures. If badge revocation latency matters, test how long it takes for a revoked credential to lose access under normal and worst-case operational loads.
Build mitigations that align with the scenario, not the technology
Mitigations fail when they are chosen because a product exists, rather than because they reduce the risk in your scenarios. The best mitigations come from understanding the attacker’s path and removing the leverage points they need.
For physical access, mitigations often fall into a few categories. Rather than listing everything, think in terms of control layering:
- Prevent entry: stronger enforcement at the door, door hardware upgrades, tighter credential checks. Deter and slow down: delays, friction in the workflow, access rules that require action rather than passive movement. Detect quickly: alarms that go to the right people, camera coverage that captures distinguishing evidence. Respond effectively: procedures and training that reduce dwell time for intruders. Recover and learn: after-action review that feeds back into configuration changes.
One trade-off that comes up constantly is security versus usability. If you add strict entry procedures without operational buy-in, staff find workarounds. Threat models should anticipate that behavior. If a policy causes constant false alarms, the organization will quietly reduce its own enforcement.
In practice, I try to define what “tolerable friction” looks like. If employees need to enter during busy periods, you can still reduce risk, but you might use a combination of controlled access, better training, and tuned alarm thresholds rather than simply making the system more rigid.
Make the credential and human workflow part of the model
Physical access points are controlled by both machines and humans. Credential issuance, badge returns, visitor processes, and contractor management are where many incidents originate.
You can treat the human workflow as its own “system,” complete with inputs, outputs, failure modes, and timing.
For instance, consider credential lifecycle:
- Issuance: who approves access and what documentation supports it. Activation: how quickly new credentials become effective and whether any lag creates temporary over-privilege. Revocation: what happens when someone leaves, when a project ends, or when they change roles. Replacement: what happens when a badge is lost or stolen.
A threat model should also cover the “temporary exception culture.” When an organization is understaffed, it often creates temporary shortcuts that become permanent. This is where physical access can quietly expand. A door that should remain restricted might be opened “just this week,” then stays that way after the week ends because nobody updates access groups.
A simple rule that helps: if access can be granted without an auditable trigger, assume it can become a threat scenario.
Keep the model alive with configuration change control
Threat models become stale the moment the building changes. Doors get replaced, readers get reconfigured, alarms move to different monitoring staff, and access group logic evolves.
To keep the model useful, tie it to change control:
- When a reader is replaced, update the model with its new failure behavior, alarm behavior, and any differences in credentials. When zones change, re-evaluate pathways that create new movement options. When staffing changes, re-evaluate response time assumptions.
You do not need a heavy bureaucratic process. You do need ownership. If the model lives in someone’s inbox, it will not survive the next relocation.
I’ve seen a particularly common failure: the building gets renovated, and construction crews get keys or master access. Even when they return keys, the access control configuration might not fully revert because schedules are tight and someone forgets to remove temporary access rights. A living model would flag that as a known scenario with a known validation checklist.
Document evidence and assumptions so decisions can be defended
A threat model is also an audit artifact, even when nobody asks for it. Future teams will want to know why you chose a mitigation.
To keep it defensible, document:
- Assumptions: what you believed about staffing, response times, and how systems behave during outages. Evidence: what you observed, measured, or tested. Rationale: why you prioritized certain access points over others.
This matters because physical security projects often compete for limited funding. If you can explain why you focused on two doors near a loading route and not on a low-traffic office entrance, stakeholders understand you are not guessing.
It also reduces internal conflict. People get attached to their doors, their cameras, their favorite sensors. When decisions are grounded in scenarios, it becomes easier to keep focus on risk.
A practical workflow you can run in a day or over a couple weeks
You can build a credible initial threat model without turning it into a multi-month program. The goal is to get to decisions and tests, then iterate.
Here is a compact workflow that works in many organizations.
Inventory the access points and define protected zones, then capture how people move between them. Write top threat scenarios for each critical access point, focusing on the paths an adversary would follow. Evaluate controls and monitoring by failure mode, especially power loss, alarm routing, and credential lifecycle. Score scenarios consistently, then pick a small set for mitigation and validation based on feasibility and impact. Produce a short mitigation plan linked to scenarios, including what to test and how to measure improvement.The “day one” output usually looks like a rough map, a scenario list, and a handful of prioritized mitigations. That is enough to start. Over time you refine scenario detail and validation results.
Two examples of how scenario thinking changes mitigation choices
Example 1: The door is strong, the workflow is not
A mid-sized company installed modern card readers on perimeter doors. On paper, the doors were secure. During a drill, the security lead discovered that badge revocation was processed by a contractor badge administrator who only ran weekly updates. A contractor could return for multiple days after the badge should have been removed.
Scenario thinking changes the mitigation. Upgrading the lock hardware would do little. The mitigation becomes operational: automate revocation workflows, shorten update intervals, add verification, and test the process during onboarding and offboarding.
Example 2: Tailgating is a behavior problem, not a reader problem
Another site had accurate readers and a well-designed badge policy, but the lobby door was frequently held open by employees because of accessibility needs and the volume of packages.
In threat modeling, tailgating remains feasible even when the reader works perfectly. Mitigation decisions shifted toward engineering and enforcement: door management devices, improved signage and staff training, and more reliable detection and response when the door is forced open or left in an abnormal state.
In both cases, the scenario writing prevented a “tech-first” answer. It grounded mitigations in what an adversary actually exploits.
Common mistakes that derail physical access threat models
Physical threat models fail in predictable ways. These are the ones I watch for first:
- Treating the model as a checklist instead of a set of scenarios that drive decisions. Ignoring response and monitoring workflows, then being surprised when “secure” controls do not matter operationally. Assuming failure modes are rare when they are actually common, like camera downtime during maintenance or power flickers that change lock behavior. Over-scoring obscure attack paths while under-scoring the credible ones that align with daily operations.
A threat model should be uncomfortable, but it should not be fictional. If your scenarios only make sense in a spy movie, you may be missing the everyday pathways that real adversaries use.
What success looks like after you build it
Success is not a perfectly complete spreadsheet. Success is that the organization makes better choices with less argument, and the chosen mitigations measurably reduce risk in the scenarios you identified.
You know the effort is working when:
- Teams can explain why a door is prioritized, and what mitigation reduces which scenario step. Testing finds issues with monitoring, timing, or process, not just with hardware assumptions. Change control updates the model, so new renovations do not silently create new pathways. Security policies align with how people actually behave, not how policy writers hoped they would behave.
If you can get to that point, the threat model stops being a static deliverable and becomes an operational tool.
Keeping it manageable as the building evolves
Facilities evolve, and threat modeling should evolve with them. A model that grows without pruning becomes unusable. The trick is to keep it small where it matters, then expand only when something changes significantly.
A practical way to manage scope is to treat “critical access points” as first-class objects in the model, and treat other points as supporting detail. When you upgrade major components, only then do you deep-dive the scenarios for that area.
If you do renovations, the best time to update the model is during planning, when changes are cheap. Waiting until after a construction phase ends is almost always more expensive, because you end up retrofitting controls to a building that is already optimized for convenience.
A short checklist for your next review session
When you revisit your model, don’t overthink it. Focus on the questions that keep it honest. Use this as a quick session framework.
- Are the top scenarios still credible given current staffing, hours, and visitor flows? Did any recent changes affect failure modes, like power backups, network routing, or controller replacements? Are alarms routed to people who can actually respond within your assumed time window? Are credential lifecycle steps still consistent with how access is granted in practice? Do your validations cover the failure modes most likely to occur, not just the most dramatic ones?
If you answer those questions with evidence and clear updates, your threat model will keep paying dividends long after the initial workshop.
Final thought on physical threat modeling
Physical access security is a blend of engineering, process, and human behavior. A threat model that respects that blend does not just describe doors. It describes movement, leverage, and response. It makes trade-offs explicit. And it gives your team a shared language for deciding what to fix first.
If you build it around scenarios and keep it alive through change control, you get something rare in security work: a model that improves your day-to-day decisions, not just your documentation.