Skip to main content
PHYSICAL SECURITY - ROLE PROFILE

Integration Engineer / Systems Integrator

Federal figures put this role between $49,510 and $115,700 a year, with a national median of $78,190.

The role

What the job actually is.

Designs and commissions security systems that have to work together and with the rest of the building: access control to video to intrusion to visitor management, directory and identity integration, server and storage sizing, network architecture, and the cutover plan for a system that cannot be down.

Pay

What this role pays.

We have not closed enough physical security searches to publish a band of our own for this seat, so the figures above are the federal 10th to 90th percentile spread rather than a My Trade Talent band. They are national and not adjusted for experience or region.

The federal occupation for this role is Electrical and Electronic Engineering Technologists and Technicians (SOC 17-3023), May 2025. Nationally it reports a median of $78,190 , with the middle of the market between $49,510 and $115,700.

Where it pays most.

Electrical and Electronic Engineering Technologists and Technicians across the metros we cover, May 2025. BLS publishes a median for 96 of them and withholds the rest, where the local sample was too small to be reliable.

Highest-paying metros - Electrical and Electronic Engineering Technologists and Technicians
Metro Median Employed there
Bakersfield $103,170 540
Baton Rouge $102,380 290
Albuquerque $102,250 390
Seattle $98,180 1,570
Virginia Beach $96,870 1,430
Las Vegas $96,660 750
Augusta $96,400 130
San Jose $95,280 2,880
Deltona-Daytona $57,750 110
Columbus $60,260 750
Harrisburg $60,750 180

BLS Occupational Employment and Wage Statistics, May 2025. The last three rows are the lowest-paying metros in the same set. Headcount is metro-wide across every industry, not this trade alone.

Credentials

Credentials that move an offer.

No single credential reliably moves an offer in this seat. Employers screen on demonstrated commercial experience instead, which makes the resume harder to read and the reference check worth more.

Licensing is a state question, not a national one. The Physical Security hiring page carries the state-by-state position, and every market page names the authority for that state.

Screening

What separates a strong candidate.

Everyone who applies for this seat will claim the experience. These are the things that distinguish the people who have it, and the questions that find out.

What to look for

  • Thinks in systems and interfaces rather than devices
  • Has done an identity or directory integration and can describe what broke
  • Can size storage and bandwidth for a camera count and retention requirement

Questions that find out

  • How do you size recording storage for a two hundred camera system at thirty days? A strong answer Builds it from the actual variables rather than a rule of thumb: per-camera bitrate at the resolution, frame rate and codec in use, how much is continuous versus event recording, the scene complexity that drives variable bitrate, the retention period, and whether redundancy or failover storage doubles it. Allows headroom and states the assumptions. Knows a system sized on an average bitrate will run out in the first busy week.
  • Walk me through integrating access control with an enterprise directory. A strong answer Treats it as an identity project, not a cable: which system is authoritative for identity, what triggers provisioning and, more importantly, de-provisioning, which attributes map to access levels, how groups drive permissions, and what happens when the link is down. Works with the client's identity team rather than around them. Says the leaver process is the point of the integration and the part most implementations get wrong.
  • How do you cut over a live access control system without leaving doors unsecured? A strong answer Plans it door by door with a fallback for each: the old system stays live until each door is proven, the hardware is swapped in a window with a guard or a mechanical key as the interim, and credentials are loaded and tested before the swap rather than after. Does a pilot group of doors first. Has a documented rollback. Tells the client's security team the sequence so they know what is unprotected and when.
  • How do you design a system that has to work across sites on one head end? A strong answer Starts with the network between sites and what it can actually carry, because the WAN decides the architecture: recording at the edge with central viewing is usually right, not streaming everything back. Plans for a site losing its link - local recording and local access decisions continue - and for how it resynchronises. Thinks about who administers what centrally versus locally, and about time synchronisation across the estate.
  • How do you decide what belongs on the network team's side and what is yours? A strong answer Settles it in writing early: who owns the VLANs, addressing, switch configuration, PoE, firewall rules and patching, and who owns the devices and the application. Knows security systems on a corporate network are the network team's risk as well as yours, so brings them in at design rather than asking for ports at commissioning. Says the handover boundary is where most integration projects stall.
  • How do you handle a client requirement that the manufacturer does not support natively? A strong answer Says so plainly rather than promising and hoping. Works through the options honestly: a supported API or SDK with the integration effort priced, a middleware product, a different manufacturer, or changing the requirement. Prototypes before committing. Knows that custom integration becomes somebody's support burden for years and says who will own it. Does not sell a roadmap promise as a delivered feature.
  • How do you test an integration before it goes live? A strong answer Tests against the scenarios that matter rather than that the link is up: the normal case, the failure case, and what happens when one side is unavailable or returns something unexpected. Builds a test environment or a limited pilot rather than testing in production. Tests the de-provisioning and the alarm paths, because those are the ones nobody exercises until they are needed. Writes the tests down and runs them again at handover.
  • What is your approach to cybersecurity on a security system you install? A strong answer Treats the system as an attack surface: default credentials changed and recorded properly, firmware on a supported version with a patching plan, devices on a segmented network rather than the flat corporate LAN, unnecessary services and ports closed, certificates where they are supported, and remote access through the client's own method rather than a vendor back door. Knows cameras are a common entry point and says so to clients.
  • How do you gather requirements from a client who does not know what they need? A strong answer Asks about the problem rather than the product: what has happened that prompted this, who will use the system and for what, what decisions they need to make from it, what their incident process is, and what they are required to do by policy or regulation. Walks the site with them. Writes the requirements back in their language for sign-off. Says a client asking for a hundred cameras usually has three real problems.
  • What is your approach to redundancy and failover on a head end? A strong answer Decides from what an outage actually costs rather than adding redundancy everywhere: which functions must survive - door decisions, recording, alarm handling - and which can wait. Knows door controllers should make decisions locally when the head end is down and that recording should continue at the edge. Designs the failover and then tests it by pulling the plug, because untested failover is a belief rather than a capability.
  • How do you handle a client security policy that restricts your remote access? A strong answer Works within it rather than around it: uses their jump host, their VPN and their approved process, with named accounts and logging, and accepts that it slows support. Prices the support model accordingly rather than quoting as if they had free remote access. Says that a vendor who asks for an exception to the client's security policy on a security system has made the wrong first impression.
  • What is your process for a phased migration from an old platform? A strong answer Runs both systems in parallel through the transition with a clear boundary of what is on which, migrates in logical groups - a building, a floor, a door type - rather than by convenience, and proves each phase before the next. Keeps the old system's data accessible for its retention period. Has a rollback per phase. Sets the end date for the old platform and sticks to it, because parallel running forever is its own failure.
  • How do you manage firmware and software version control across an estate? A strong answer Keeps a record of what version is where, tests updates in a lab or a pilot site before rolling them out, and schedules rather than patching reactively - except where a vulnerability forces it. Knows version mismatches between head end and edge devices break integrations, and that manufacturers drop support for older hardware. Plans the estate's refresh rather than discovering a device can no longer be patched.
  • What is your approach to integrating video, access and intrusion in one interface? A strong answer Starts from the workflow: what the operator needs to see and do when an event happens, and builds the integration to serve that rather than to tick a feature. Links events to video so an alarm brings the footage with it, and keeps the interface sparse enough to be used under pressure. Is honest about which parts are genuinely integrated and which are three systems behind one window.
  • How do you handle a manufacturer bug that blocks a deliverable? A strong answer Reproduces it and documents it properly before escalating, gets a case open with the manufacturer and a named contact rather than a general support queue, and pushes for a timeline. Tells the client immediately with the workaround and the impact rather than absorbing it quietly and missing a date. Has a position on what happens if the fix does not come: a workaround, a different approach, or a commercial conversation.
  • How do you train a client team to run the system after you leave? A strong answer Trains the people who will actually use it, on their system with their data, split by role - operators, administrators and whoever manages cardholders - rather than one session for everybody. Has them do the tasks rather than watch. Leaves written procedures for the common jobs and a named escalation route. Comes back after a few weeks, because the real questions appear once they have used it.

The mistake this seat invites

Hiring a field technician into a design seat. The integration role is architecture and commissioning, and the failure mode is a system that passes device-by-device and fails as a whole.

Where the role goes next

Integration engineers move to solutions architect, engineering manager, or to the manufacturer side. Candidates ask this in the first conversation, and an employer who cannot answer it loses the people who had other options.

Interview kit for this role

The search

What the search actually takes.

We have not closed a physical security search in 2026 year to date, so we publish no timing figure of our own for this seat rather than borrow one. The Hiring Index shows the trades where we do.

What we have open in Physical Security right now.

One live physical security search on our board as of November 12, 2026. These are roles contractors have asked us to fill, not a sample set.

Keep reading.

All 56 roles we recruit - every trade, every seat.

Trade Talk A monthly hiring brief for commercial trades employers

What changed in your trade this month, and what to do about it.

One email a month, and only one. We write a separate issue for every trade we recruit in, so you get yours - not a round-up with your trade buried in paragraph nine. Every issue is written for the person actually doing the hiring.

  • Where wages moved in your trade, by market, and what that does to your next offer
  • How long roles like yours are taking to fill, and where it is getting worse
  • Interview and screening tactics that are landing candidates this month
  • What contractors competing for the same people are doing differently

Built on federal wage data, our own closed searches, and what we hear on the desk every week. Written for employers, not candidates. No pitch, no filler, one click to leave.

Pick your trade. That is the one issue you get, once a month.

One email a month. Your trade and your address, nothing else - we do not sell either, and you can unsubscribe from the bottom of any issue. Read this month's issue for your trade first →