Sunstates Security and SOC Architecture: How to Connect Physical Signals to Cyber Response
A SOC can see impossible travel, suspicious badge timing, EDR detections, VPN anomalies, and visitor logs in five different systems. The incident still gets handled in a spreadsheet because nobody owns the handoff between physical security and cyber response.
That is why searches for Sunstates Security are often more operational than they look. A team may be evaluating a guarding provider, comparing physical security operations, or trying to understand how a provider fits into a broader security program. The real question is not just who staffs a post. It is whether the signals from that post become usable security operations data.
Teams think the problem is vendor selection. The real problem is architecture. If your SOC cannot turn access events, guard observations, site incidents, visitor exceptions, and cyber telemetry into one investigation workflow, the provider name matters less than the operating model around it.
The practical question is this: if Sunstates Security or any physical security partner is part of your environment, how do you connect that partner to detection engineering, incident response, threat intelligence, and executive risk decisions without creating another disconnected queue?
Table of contents
- Sunstates Security is an operating model question
- Where Sunstates Security fits in your SOC architecture
- The signals your SOC should expect from physical security
- Design the workflow before you buy integrations
- What works and what fails in cyber physical operations
- Detection engineering for Sunstates Security adjacent events
- Incident response when the first signal is physical
- Metrics that prove the workflow is working
- Common failure modes when physical security stays disconnected
- How threatcrush.com fits the operating model
Sunstates Security is an operating model question
Why this search shows up in SOC planning
When SOC engineers search for Sunstates Security, they are rarely trying to memorize a definition. They are usually in one of three situations.
They are supporting a business unit that already uses a physical security provider. They are part of a merger, site expansion, office consolidation, or data center program. Or they are being asked why a cyber incident was not connected to a physical event that happened the same day.
That changes the conversation. The SOC is not just monitoring endpoints and cloud logs anymore. It is participating in a wider protection workflow that includes doors, people, visitors, cameras, radio traffic, contractors, badge exceptions, and local response.
The mistake teams make is treating physical security as a parallel department. In production, parallel departments become parallel timelines. One timeline says a laptop was seen leaving a restricted area. Another says the same user generated unusual SaaS downloads. A third says the badge was used after hours. Nobody connects the three until the post incident review.
A useful way to think about it is this: Sunstates Security may be the searched term, but the SOC problem is signal routing. If the signal cannot be normalized, enriched, assigned, investigated, and closed with evidence, it is not part of the detection program. It is only an observation.
The cyber physical handoff
The cyber physical handoff is where most programs break. A guard may notice tailgating, a propped door, a visitor mismatch, or suspicious behavior near a sensitive area. The SOC may see endpoint activity, identity anomalies, VPN failures, cloud downloads, or privileged access changes. The business sees one risk. The tools see several unrelated events.
The handoff needs three things:
- A shared incident taxonomy
- A defined escalation owner
- A way to preserve context across teams
Without those, the handoff becomes a phone call and a chat message. That can work once. It does not scale across multiple offices, shifts, regions, and incident types.
Practical rule: If a physical security observation can change the severity of a cyber alert, it needs a defined path into the SOC workflow.
This does not mean every guard report belongs in the SIEM. It means the subset of events that affect identity, access, asset movement, executive safety, sensitive areas, or insider risk should be modeled as security signals. That model should exist before anyone argues about platforms.
Where Sunstates Security fits in your SOC architecture
Signals before tools
The practical question is not whether your SIEM can ingest every available feed. It probably can, and that is not always good news. The better question is which physical security events should affect triage, detection, response, and risk scoring.
For a SOC, Sunstates Security should be considered in terms of signal categories, not brand assumptions. Avoid building an architecture around a vendor label. Build around events that matter:
- Badge access granted or denied
- Repeated access failures
- After hours access
- Visitor exceptions
- Escort violations
- Lost or recovered badges
- Restricted area alarms
- Guard incident reports
- Asset removal observations
- Law enforcement or emergency response involvement
Some of these signals are structured. Some are not. Some arrive in access control systems. Others arrive in shift reports, case systems, email, or dispatch notes. What breaks in practice is pretending all signal types have the same fidelity.
Structured badge events can be correlated automatically. Human observations often require review, classification, and follow up. A good architecture allows both, without forcing every observation into a brittle automation path.
Ownership before escalation
Ownership is more important than tooling. If a badge anomaly triggers a cyber investigation, who owns the case? The SOC? Corporate security? Site leadership? HR? Legal? The answer may change by incident type, but it cannot be undefined.
Use a simple ownership model:
| Event type | Primary owner | SOC role | Physical security role |
|---|---|---|---|
| After hours badge plus risky login | SOC | Correlate identity and endpoint activity | Confirm site context |
| Tailgating into sensitive area | Physical security | Check related account and asset activity | Investigate site event |
| Lost badge for privileged user | Identity team | Monitor account risk and session activity | Disable or replace credential |
| Visitor exception near restricted zone | Site security | Enrich with watchlists or active threats | Validate visitor record |
| Asset removal concern | Joint owner | Preserve endpoint and data movement evidence | Preserve physical observation |
This table is not a policy. It is a starting point. The key is to assign a primary owner and a supporting owner before an incident happens.
Related reading from our network: teams evaluating remote operations tooling face a similar ownership problem, and this remote access software architecture guide is useful when thinking about access, support boundaries, and operational control.
The signals your SOC should expect from physical security
Access control and identity events
Access control is the easiest place to start because the data is usually structured. Badge systems already produce timestamps, locations, user identifiers, door identifiers, and decision outcomes. The SOC value comes from correlation.
Useful correlations include:
- Badge access in one geography while VPN login occurs from another
- Badge denied at sensitive area followed by cloud file access
- Terminated employee badge activity after identity disablement
- Privileged user entering site shortly before unusual admin activity
- Multiple failed badge attempts paired with password spraying
- Badge use during approved travel absence
These are not magic detections. They are simple joins across identity, access, endpoint, network, and physical telemetry. The hard part is getting the identifiers right.
A common failure mode is mismatched identity keys. Physical access systems may use employee ID, badge ID, email alias, contractor ID, or a local naming convention. Cyber tools may use UPN, email, device owner, HR ID, or SSO subject. If those fields are not mapped, correlation becomes manual.
Practical rule: Do not build physical cyber detections until identity mapping is reliable enough to survive contractors, name changes, shared locations, and terminated users.
The first engineering task is usually not a detection rule. It is a join table.
Human observations and site exceptions
Human observations are messy but valuable. A guard report can contain context that no sensor has: a person looked nervous, a contractor arrived with the wrong escort, a vehicle circled a facility, a door was propped intentionally, an employee tried to bypass process, or a visitor claimed a meeting that did not exist.
The SOC should not ingest every sentence of every shift log as an alert. That creates noise and destroys trust. Instead, define categories that can affect cyber risk:
- Identity concern
- Asset concern
- Restricted area concern
- Visitor concern
- Executive or VIP concern
- Suspicious surveillance concern
- Policy bypass concern
- Emergency response concern
Each category should have severity guidance and routing logic. For example, a visitor concern at a general office lobby may remain with physical security. The same concern at a data center, lab, finance floor, or executive area may create a SOC notification.
A useful way to think about it is that human observations are enrichment first and alerts second. They should explain what the cyber tools cannot see. When they do trigger alerts, they should do so because the event affects access, identity, asset movement, or active threat context.
Design the workflow before you buy integrations
A practical implementation sequence
Buying integrations before designing the workflow usually creates a faster mess. The SOC receives more events, but responders still do not know who to call, what evidence matters, or when to escalate.
Use this implementation sequence instead:
- Inventory physical security systems, providers, sites, and reporting channels.
- Identify event categories that can affect cyber risk.
- Map identifiers between HR, identity, access control, endpoint, and case systems.
- Define ownership for each event category and severity level.
- Create a shared incident taxonomy across cyber and physical teams.
- Build a small set of high confidence correlation rules.
- Route cases into the system of record, not a temporary mailbox.
- Test the workflow with tabletop scenarios and live low severity events.
- Measure triage time, escalation time, duplicate cases, and closure quality.
- Expand only after the first workflow is stable.
This sequence is slower than connecting an API and dumping logs into the SIEM. It is also less likely to fail.
Practical rule: Integrate the workflow first, then integrate the data. Otherwise you automate ambiguity.
If you want a broader SOC workflow foundation before connecting physical security signals, our guide to security operations in 2026 covers the operating model, tooling layers, and maturity roadmap that these integrations depend on.
Minimum viable data model
You do not need a perfect data model to start. You need a minimum viable one that supports correlation, assignment, and audit.
At minimum, normalize these fields:
| Field | Why it matters | Example use |
|---|---|---|
| Person identifier | Connects physical and cyber identity | Badge event to SSO account |
| Site identifier | Adds location context | Office, data center, lab |
| Event category | Enables routing | Visitor, badge, asset, restricted area |
| Event time | Supports correlation windows | Badge use before login anomaly |
| Source system | Preserves provenance | Access platform, guard report, dispatch |
| Severity | Drives response priority | Informational to critical |
| Case owner | Prevents orphaned work | SOC, site security, identity team |
| Evidence pointer | Supports investigation | Report ID, camera reference, ticket link |
Do not overfit the model to one provider or one site. The model should work if the company changes guarding provider, adds a new access control platform, or brings a new facility online.
What breaks in practice is location naming. One system says NYC HQ. Another says New York Office. Another says Building 12. Another uses a cost center. If you do not normalize site identifiers, your detections will look precise but behave badly.
What works and what fails in cyber physical operations
What works
The teams that make cyber physical workflows useful tend to do a few things consistently.
They start with a small number of high consequence scenarios. They avoid trying to ingest everything. They make physical context visible to analysts without forcing analysts to become facility experts. They build bidirectional escalation paths. They run tabletop exercises with real tooling, not slides.
Good starting scenarios include:
- Privileged user physical access plus suspicious admin activity
- Lost badge plus active sessions
- Terminated worker badge activity plus account activity
- Unauthorized access attempt plus endpoint movement
- Visitor exception plus executive threat intelligence
- Propped door near sensitive area plus device discovery
These scenarios work because they have clear operational meaning. They are not generic anomalies. They connect a physical event to a cyber risk that a SOC can investigate.
What also works is keeping enrichment close to the alert. Analysts should not have to open five systems to answer basic questions. Who is the person? What site is involved? Is the person active, terminated, contractor, visitor, or executive? What assets are assigned? Are there current threat indicators involving the site, brand, executives, or sector?
What fails
The mistake teams make is building the integration around visibility instead of action. Visibility says the SOC can see badge logs. Action says the SOC knows which badge logs matter, who owns them, and what to do next.
Common failures include:
- Sending all access events into the SIEM without filtering
- Treating every guard report as an alert
- Creating cyber cases with no physical owner
- Creating physical cases with no cyber enrichment
- Using email as the system of record
- Ignoring identity mapping quality
- Failing to distinguish employees, contractors, visitors, and vendors
- Not testing after hours and weekend escalation
The result is predictable. Analysts suppress the noisy feed. Site teams stop sending context because nothing happens. Leadership believes integration exists because a dashboard exists. During a real incident, everyone falls back to calls and screenshots.
Related reading from our network: communication architecture matters in incident work, and this piece on end-to-end encrypted messaging is a useful adjacent read for teams thinking about secure escalation paths and operational privacy.
Detection engineering for Sunstates Security adjacent events
Correlation rules that are worth writing
Sunstates Security adjacent detections should be written around behaviors and risk intersections, not around the provider name. The provider may supply personnel, observations, or operational context, but the detection logic should remain portable.
Start with rules that have a clear reason to exist:
| Detection idea | Required sources | Why it matters |
|---|---|---|
| Badge use after termination | HR, access control, IAM | Indicates process failure or credential misuse |
| Impossible physical cyber travel | Badge, VPN, IdP | Highlights account sharing or compromise |
| Denied restricted access plus data access | Access control, DLP, SaaS logs | Connects physical probing to data risk |
| Lost badge plus privileged session | Guard report, PAM, EDR | Raises risk for high value accounts |
| Visitor exception plus threat intel | Visitor system, intel, case data | Adds context to targeted activity |
A simple correlation pattern can look like this:
rule: after_hours_badge_plus_risky_login
window: 60m
join_key: normalized_person_id
conditions:
- physical.event_type: badge_access_granted
- physical.site_sensitivity: high
- physical.local_time: outside_business_hours
- identity.risk_score: elevated
- identity.event_type: interactive_login
route_to: soc_tier_2
required_enrichment:
- user_status
- manager
- assigned_assets
- site_contact
- recent_cases
This is intentionally plain. The value is not in clever syntax. The value is in the join key, the time window, the severity logic, and the routing decision.
Enrichment that reduces investigation time
Most analysts do not need more alerts. They need the first alert to arrive with enough context to make a decision. For physical cyber cases, enrichment should answer practical questions quickly.
Useful enrichment includes:
- Person status: active, terminated, contractor, visitor
- Role sensitivity: executive, administrator, finance, engineering, support
- Site sensitivity: office, lab, data center, restricted floor
- Asset ownership: laptop, mobile device, privileged workstation
- Recent cyber activity: logins, EDR alerts, SaaS downloads
- Recent physical activity: badge pattern, denied access, guard reports
- Threat context: active campaigns, targeted executives, sector threats
- Case history: prior incidents involving person, site, or asset
This is where threat intelligence becomes operational instead of decorative. If a site is mentioned in a threat actor discussion, an executive receives threats, or a sector campaign is active, that context should modify triage. It should not live in a PDF that analysts never open.
For deeper workflow design around enrichment, correlation, and analyst handoffs, see our guide to threat analysis workflows that actually work.
Incident response when the first signal is physical
Escalation paths and communications
Sometimes the first useful signal is not an EDR alert. It is a guard observation, a visitor issue, a door event, or a call from a site leader. If the SOC treats that as outside its lane, the response starts late.
Define escalation paths by incident type:
- Physical observation only
- Physical event with cyber context
- Cyber alert requiring physical validation
- Executive or VIP concern
- Insider risk concern
- Facility disruption affecting security monitoring
- Law enforcement or emergency response involvement
Each path needs a primary channel, backup channel, approver, evidence owner, and case system. Do not rely on one person knowing who to call.
A practical escalation entry might look like this:
scenario: restricted_area_tailgating_plus_endpoint_alert
primary_owner: site_security
soc_owner: incident_commander
notify:
- soc_tier_2
- physical_security_manager
- identity_on_call
- legal_if_employee_investigation
sla:
acknowledge: 15m
initial_correlation: 30m
evidence:
- guard_report_id
- badge_event_ids
- endpoint_alert_ids
- camera_reference_if_available
Related reading from our network: local coordination problems look different outside the SOC, but the same routing and trust issues show up in community operations; this guide to Mighty Networks alternatives for local communities is an adjacent example of workflow design around people, location, and follow up.
Evidence handling and auditability
Physical cyber incidents can touch HR, legal, privacy, labor rules, customer obligations, and law enforcement. Evidence handling matters.
The SOC should not casually copy sensitive physical security material into every tool. Camera references, guard notes, visitor details, and employee observations may need restricted access. The case record should preserve evidence pointers and access controls, not scatter screenshots across chats.
Good evidence handling includes:
- Clear source of record for physical evidence
- Clear source of record for cyber evidence
- Timestamp normalization across systems
- Chain of custody where required
- Role based access to sensitive notes
- Separation between allegation and confirmed fact
- Retention aligned to policy
What breaks in practice is over sharing during urgency. A screenshot seems harmless until it contains visitor data, employee behavior notes, or sensitive facility details. Build the evidence workflow before the first serious case.
Practical rule: Treat physical security context as sensitive evidence, not generic enrichment. Give analysts what they need, but preserve access boundaries.
Metrics that prove the workflow is working
Operational metrics
You cannot prove the value of a Sunstates Security integration, or any physical security integration, by counting ingested events. High event volume may mean progress. It may also mean you created noise.
Better operational metrics include:
- Percentage of physical cyber cases with assigned owner
- Time from physical event to SOC awareness
- Time from cyber alert to physical validation
- Duplicate case rate across teams
- Percentage of cases with normalized person and site identifiers
- Percentage of escalations handled within SLA
- Number of unresolved ownership conflicts
- Number of tabletop findings closed
These metrics show whether the workflow is usable. They also expose where the program is pretending. If half of cases lack normalized identity, detection engineering will not scale. If duplicate cases are common, teams are not sharing a system of record. If after hours escalation fails, the workflow only exists during business hours.
Detection and response metrics
Detection metrics should focus on signal quality and response impact.
Useful measures include:
- True positive rate for physical cyber correlation rules
- Suppression rate by rule and site
- Mean time to triage for correlated cases
- Mean time to contain when physical context is present
- Number of incidents where physical context changed severity
- Number of incidents where cyber context changed physical response
- Analyst feedback on enrichment usefulness
Be careful with executive dashboards. A chart that says physical security events increased by 40 percent is not necessarily meaningful. A chart that says correlated cases now reach the correct owner in 12 minutes instead of waiting for next day review is much more useful, if you can measure it honestly.
The practical question is not whether the integration is busy. It is whether it changes decisions.
Common failure modes when physical security stays disconnected
The duplicate case problem
Disconnected physical and cyber teams often investigate the same incident without realizing it. Physical security opens a case about unusual access. The SOC opens a case about suspicious login behavior. HR asks for background. Identity disables something. Facilities checks cameras. Everyone has partial context.
The duplicate case problem causes several operational issues:
- Conflicting timelines
- Missed severity changes
- Repeated outreach to the same people
- Evidence stored in multiple places
- Slow containment decisions
- Confusion during executive briefings
The fix is not one universal tool for everyone. That is rarely realistic. The fix is a shared case reference, common taxonomy, and clear linking between systems. If the SOC and physical security must use separate systems, each case should still contain the other case ID and owner.
The blind escalation problem
Blind escalation happens when one team sends a case to another team without enough context to act. A guard report says suspicious person. A SOC alert says risky user. An identity ticket says disable account. None of them explain the business risk.
Blind escalation creates delay because the receiving team has to rediscover context. It also creates bad automation. If escalation payloads are thin, automated routing will send work to the wrong queue.
A minimum escalation payload should include:
- What happened
- Why it matters
- Who or what is involved
- Where it happened
- When it happened
- What has already been validated
- What decision is needed
- Who owns the next action
This is basic, but many production workflows miss it. They send an alert title and a link. That is not escalation. That is a breadcrumb.
How threatcrush.com fits the operating model
Where a threat intelligence layer helps
Threat intelligence is useful in this workflow when it changes prioritization, enrichment, or response. It is not useful when it becomes another feed that analysts ignore.
In a cyber physical operating model, intelligence can help answer questions like:
- Is this site, executive, brand, or sector being discussed by threat actors?
- Are there active campaigns targeting similar organizations?
- Is a visitor name, domain, IP address, handle, or company linked to known risk?
- Are recent vulnerabilities relevant to exposed systems at this location?
- Are there external signals that should raise the severity of a local event?
That is where a real time threat intelligence layer can support SOC and physical security collaboration. It gives analysts context before they decide whether a physical event is routine, suspicious, or part of a broader campaign.
This is also where continuous threat exposure management becomes relevant. Physical events can expose weak points in process. Cyber telemetry can expose weak points in control coverage. Intelligence can explain whether those weak points are likely to be exploited now.
What to connect first
Do not connect everything first. Connect the sources that improve decisions fastest.
A practical first phase looks like this:
- Identity provider logs
- HR status or identity lifecycle data
- Access control events for sensitive sites
- SOC case management
- High severity guard incident categories
- Threat intelligence context for executives, sites, sectors, and exposed assets
After that, add visitor systems, asset movement workflows, camera references, dispatch systems, and regional site processes where justified.
If your team is building this kind of operating model, ThreatCrush is designed for security operations professionals who need real time threat feeds, vulnerability tracking, attack surface monitoring, and threat actor intelligence connected to actual SOC workflows.
The closing point is simple: Sunstates Security may be the term that starts the conversation, but the durable work is building a cyber physical security workflow that routes signals, enriches cases, assigns ownership, and validates response.
Try threatcrush.com
You are writing for security operations professionals building and scaling SOC capabilities. Try threatcrush.com.
Try ThreatCrush
Real-time threat intelligence, CTEM, and exposure management — built for security teams that move fast.
Get started →