[ Secure Gateway Module (SGW / SGM) ]

Reference notes on the Secure Gateway Module (SGW on Stellantis paperwork, SGM in the aftermarket) found on 2018+ FCA / Stellantis vehicles — what it is, what it gates at the OBD-II port, how the AutoAuth subscription path works, what physical bypass means, and how to decide between paying for a certified tool, paying for AutoAuth, or installing a hardware bypass. Written from the perspective of someone who actually works on these cars rather than someone trying to sell you a $5,000 scan tool.

[ What it is ]

The Secure Gateway Module is a dedicated security ECU that sits between the OBD-II port and the rest of the vehicle's CAN bus network. FCA (now Stellantis) began installing it on some 2017-build vehicles that came to market as 2018 models. By 2020 nearly the entire FCA US lineup ships with one — Chrysler, Dodge, Jeep, Ram, and Alfa Romeo. Coverage is primarily North American; non-US markets often skip it.

Physical location varies by model. Common spots: behind the glove box, under the dashboard near the steering column, or co-located with the Body Control Module. On Jeep platforms it's frequently behind the glove box near the same 13-way CAN connectors discussed in the DIY OBD-II Diagnostic Cable writeup — which is one reason that behind-the-glovebox access point is so useful for research work.

CAN-C and CAN-IHS 13-way connectors located behind the JEEP glovebox — the access point that sits inside the SGW boundary, used for direct read/write CAN access without going through the SGW-gated OBD-II port

The CAN-C and CAN-IHS connectors behind the glovebox. These sit inside the SGW boundary — traffic sourced here reaches the internal buses directly without going through any of the gating the SGW applies to OBD-II-port traffic. This is why direct-CAN access via the glovebox is the recommended path on 2018+ FCA vehicles when you need write access. Same access point discussed in the DIY OBD-II Diagnostic Cable writeup; pinout and cable-build details are over there.

[ Why it exists ]

Largely a response to the 2015 Miller/Valasek Jeep Cherokee remote hack. Researchers compromised a vehicle over the cellular Uconnect connection and pivoted from the infotainment processor into the CAN bus, where they were able to control steering, brakes, and transmission behavior on a moving vehicle. The story made it onto the cover of Wired, prompted a 1.4M-vehicle recall, and forced the industry to take in-vehicle network segmentation seriously for the first time.

The SGW is FCA's architectural answer: rather than try to harden every individual ECU against a hostile attacker who has already reached the CAN bus, isolate the external attack surface (OBD-II port plus Uconnect telematics) behind one gatekeeper module that enforces policy on what crosses the boundary.

Conceptually it's the same idea as a network firewall. A chokepoint with one job: inspect requests, drop or forward based on policy, log if you care.

[ What's gated at the OBD-II port ]

Without authentication, a generic OBD-II scanner can still do everything that's read-only:

  Allowed without authentication
  ------------------------------
  - Read VIN
  - Read stored DTCs (Diagnostic Trouble Codes -- the standardised
    fault codes like P0420 or U0101 that ECUs store when something
    goes wrong; what scan tools display)
  - Read pending and permanent DTCs
  - View live data / OBD-II PIDs (RPM, coolant temp, O2 sensors,
    short and long fuel trim, MAF, MAP, throttle position, etc.)
  - Read freeze-frame data captured at the time of a fault
  - Read readiness monitors
  - Read mode 06 on-board monitoring results

  Blocked without authentication
  ------------------------------
  - Clear / reset DTCs
  - Bi-directional control (actuator tests, forced regen,
    ABS bleeding routines, etc.)
  - ECU programming or coding of any module
  - Key fob programming
  - Module replacement / configuration
  - Adaptations and relearns (TPS, throttle body, transmission,
    steering angle sensor calibration, etc.)
  - Service-mode functions (electric parking brake retraction,
    suspension calibration, etc.)

The practical effect: a $30 ELM327 dongle and a free OBD-II app on your phone still gets you everything you'd need to chase down a check-engine light. But you can't clear the code afterward without authenticating.

[ How it works at the data layer ]

The OBD-II port no longer wires directly into the internal CAN-C and CAN-IHS buses. Traffic from the port terminates at the SGW first; the SGW decides what (if anything) gets forwarded to the buses behind it:

  [ scan tool ]
        |
        v
  [ OBD-II port ]
        |
        v
  [ SGW  ] -- check request type -----+
        |                              |
        |   if read-only PID           |  if write / actuator /
        |   or basic OBD-II            |  programming request
        v                              v
  [ CAN-C / CAN-IHS ]            [ check session auth ]
   (target ECU sees it)                 |
                                        v
                                  authenticated  --> forward
                                  not auth'd     --> drop or NRC

The SGW also acts as a MITM for the Uconnect head unit. The radio talks to the SGW, not to the powertrain bus directly — so a compromised infotainment processor can't reach the brake controller without going through SGW policy. That's the architectural lesson from the Cherokee hack made concrete.

Practically, when a request is dropped, you usually see either a silent failure (no response at all) or a UDS Negative Response Code, typically 7F <service> 33 (securityAccessDenied) or 7F <service> 7E (subFunctionNotSupportedInActiveSession). A scan tool will surface this as "command failed" or "vehicle communication error" depending on how charitable its UI is.

The SGW has its own UDS endpoint. The module is addressable at $47E (request) / $47F (response) in the on-vehicle UDS address space — documented alongside the other module pairs in the BMR module-ID catalog. That means there's an authentication / introspection surface ON the gateway itself, separate from "ask the gateway to route my request to a module behind it." What's reachable at $47E without the right session credentials is largely the standard ISO 14229 read services (0x10 DiagnosticSessionControl, 0x22 ReadDataByIdentifier for non-sensitive DIDs, 0x3E TesterPresent); the deeper services that would let you reconfigure the gateway's filtering policy require seed/key unlocks the SGW does NOT hand out cheaply. Useful target for research; not a fruitful target for "defeat the gateway from the OBD-II port."

SGW pinout — physical "gate" at the wiring level

The gate isn't just architectural; it's literal on the harness. The SGW has TWO connectors — C1 for CAN-C and C2 for CAN-IHS — and each one carries three distinct pairs: a diagnostic-side input from the OBD-II port, a primary post-filter trunk to powertrain / chassis modules, and an "AT" post-filter trunk to body-domain modules.

Connector C1 (12-pin) — CAN-C side:

    SGW C1 pin   Signal                Source / destination
    ----------   -------------------   --------------------------------
    pin 3        Diagnostic CAN C(+)   <-- from OBD-II DLC1 pin 6  (D428 BG)
    pin 10       Diagnostic CAN C(-)   <-- from OBD-II DLC1 pin 14 (D427 YE)
    pin 4        CAN C(+) AT           --> to "AT" trunk (radio, body)
    pin 11       CAN C(-) AT           --> to "AT" trunk
    pin 5        CAN C(+)              --> to primary trunk (PCM, ABS, ESP)
    pin 12       CAN C(-)              --> to primary trunk
    pin 7        Fused ignition run/start (power)
    pin 6 / 8    Ground / NA

Connector C2 (8-pin) — CAN-IHS side:

    SGW C2 pin   Signal                Source / destination
    ----------   -------------------   --------------------------------
    pin 2        Diagnostic CAN IHS(+) <-- from OBD-II DLC1 pin 3  (D434 BG)
    pin 7        Diagnostic CAN IHS(-) <-- from OBD-II DLC1 pin 11 (D433 BG/YE)
    pin 1        CAN IHS(+) AT         --> to "AT" IHS trunk
    pin 6        CAN IHS(-) AT         --> to "AT" IHS trunk
    pin 3        CAN IHS(+)            --> to primary IHS trunk
    pin 8        CAN IHS(-)            --> to primary IHS trunk
    pin 5        Fused B(+) (always-on power)
    pin 4        Ground

The diagnostic-side pairs (C1 pins 3/10 and C2 pins 2/7) are the inputs everything from the OBD-II port arrives on. The "AT" suffix ("After [the gateway]") marks the post-filter downstream pairs — present on both connectors, because the SGW filters both buses identically in the policy sense, just on physically separate connectors.

The split between the primary trunk (C1 pin 5/12, C2 pin 3/8) and the "AT" trunk (C1 pin 4/11, C2 pin 1/6) is post-filter; it's a fault-isolation / routing decision, not a policy one. Powertrain-side modules (PCM, ABS, ESP, MGU, BPCM) tend to land on the primary trunk; body-adjacent modules (radio, Emergency Assistance) on the "AT" trunk.

The C2 connector having an always-on B(+) feed (A902 0.35 RD on pin 5) instead of only-ignition-on power is why the SGW remains able to gate CAN-IHS traffic during sleep / wake cycles — remote keyless entry (RKE) wakes the IHS bus while ignition is off, so the gateway needs to be alive on the IHS side to apply policy. The CAN-C side (C1) is fed by F949 0.50 PK/GN on pin 7, which is fused ignition-run/start — CAN-C is powertrain, so it doesn't matter if the SGW C1 side is dead while parked.

A scope probe placed on C1 pin 5/12 sees the SAME traffic as a probe placed at the behind-glovebox 13-way connectors, because those connectors are taps on the same vehicle-side primary trunk. Same for C2 pin 3/8 on the IHS side.

This is why the bypass-cable approach in the DIY OBD-II Diagnostic Cable guide works: it joins the behind-glovebox 13-way connectors (vehicle-side primary trunks for both CAN-C and CAN-IHS, pre-filter from the OBD-II perspective) and ignores the SGW's diagnostic-side inputs entirely. Read AND write access on both buses, no AutoAuth, no certified tool, no policy filtering — because you're plugged into the bus on the SGW's output side rather than its input side.

Full pinout tables (every cavity, wire IDs, gauges, colors, NO-CONNECT entries), connector part numbers (C1: 68080557AA full / 68316921AA terminal kit; C2: 68496366AA full / 68316921AA terminal kit), splice points (S2800-S2803 main-trunk, S17150 / S17151 eTorque- branch), and trim-variant routing notes live at BMR §SGW + CAN bus harness.

[ AutoAuth — the authentication path ]

Stellantis partnered with a third-party service called AutoAuth (autoauth.com) to gate write access. A certified scan tool, an active AutoAuth subscription, and a live internet connection are all required at the time of use — not a one-time unlock.

The authentication flow looks like this:

  1.  Tech plugs the certified scan tool into the OBD-II port.
  2.  Tool reads a challenge value from the SGW.
  3.  Tool relays the challenge to AutoAuth's servers over the
      shop's internet connection, along with the tech's account
      credentials.
  4.  AutoAuth verifies the credentials and confirms with FCA's
      registry that the tool serial is approved.
  5.  AutoAuth returns a response value to the scan tool.
  6.  Tool presents the response to the SGW; SGW unlocks the
      write-capable session for that ignition cycle.

  Session is valid until ignition off OR tool unplugged.

Cost as of 2026 is roughly $50/year per shop for up to five employees, with additional users at a few dollars each. Individual vehicle owners pay $50/year too. The tool itself must be FCA-certified — current supported brands include Snap-on, Autel, Launch X431, Topdon, Xtool, Thinkcar, and a few others. Generic ELM327 dongles and unbranded scanners cannot authenticate and never will, by design.

For full OEM-level work (key programming, full coding, ECU flashing, module replacement procedures), Stellantis's own wiTECH 2 is still the reference implementation and has direct SGW access without AutoAuth — but it requires a dealer-level subscription that's several orders of magnitude more expensive than the AutoAuth track.

[ Hardware bypass options ]

Because the SGW raises the bar for independent repair and modding, an aftermarket cottage industry has built physical bypass solutions. Three categories:

  12+8 conversion connector
  -------------------------
  A passive adapter cable that mates with the OBD-II port on
  one side and a 12+8 connector on the other. Re-routes the
  diagnostic pins to expose the internal CAN buses directly,
  bypassing the SGW's filtering. Most "SGW bypass cable" or
  "AutoAuth bypass cable" products listed on Amazon and eBay
  fall into this category. Plug in, work, unplug — non-permanent.

  Bypass harness
  --------------
  A more invasive solution: physically unplug the SGW from the
  vehicle and plug a passthrough harness into the gateway's
  vehicle-side connectors, restoring the pre-2018 direct-wired
  topology. Some harnesses retain the SGW in-line for state
  signaling but reroute its CAN connections.

  Permanent removal
  -----------------
  Some shops remove the SGW entirely on customer vehicles.
  This is the most reversible-looking option from a wiring
  standpoint but introduces compatibility risks with any
  module that expects the SGW present for state queries.

Caveats worth knowing before pulling the trigger:

  - Manufacturer warranty on related modules may be affected.
  - Some 2024+ vehicles have moved toward distributed gateway
    function across multiple modules; a single-point bypass
    doesn't fully work on those.
  - You're reintroducing the attack surface the SGW exists to
    mitigate. For a daily driver with active cellular telematics
    that's a real (if small) concern — the original Cherokee
    attack vector is now public and well-documented.
  - Some insurance policies have clauses around aftermarket
    modifications. Read yours before, not after.
  - If the vehicle gets stolen or involved in an incident, a
    bypass is exactly the sort of thing a forensics report will
    flag.

[ Practical guidance ]

How to decide which path makes sense for your use case:

  Just reading codes occasionally
  -------------------------------
  Any OBD-II scanner works. No SGW issue. A $20 ELM327 and a
  free phone app is sufficient. Don't overthink it.

  Occasional clear / bi-directional work on your own vehicle
  ----------------------------------------------------------
  Cheapest path is a low-end certified tool (Topdon TopScan,
  base Launch model) plus the $50/year AutoAuth subscription.
  Internet required at the time of use, so a phone hotspot
  works if you're in a driveway.

  Frequent professional / shop use
  --------------------------------
  Full-tier scan tool (Autel MaxiSYS, Launch X431 Pro, Snap-on
  Modis Edge / Zeus, etc.) plus AutoAuth shop subscription.
  This is standard shop equipment for any indie that touches
  FCA vehicles regularly post-2018.

  Heavy modification work / no reliable internet at the bay
  ---------------------------------------------------------
  Physical bypass harness makes more sense — no per-session
  auth, no recurring subscription, no internet dependency.
  Trade-off is everything in the caveats list above.

  OEM-level work (key programming, full coding, flashing)
  -------------------------------------------------------
  wiTECH 2 with a dealer-level subscription. AutoAuth doesn't
  cover the full surface. This is the path most independent
  locksmiths and tuners end up on if they specialize in FCA.

For research work specifically — sniffing, learning the bus layout, reverse-engineering message IDs — the SGW is largely irrelevant because direct CAN access via the behind-the-glovebox 13-way connectors (see DIY OBD-II cable writeup) bypasses it entirely. The SGW only gates traffic that arrives via the OBD-II port or the Uconnect head unit; internal taps don't cross that boundary.

[ See also ]