Chapter 33 — Device Groups — Concepts, Components & Hierarchy

Device Groups are Panorama's mechanism for managing security policy and policy objects across a fleet of firewalls. While Templates govern network and device settings (Chapter 32), Device Groups govern what traffic is allowed or denied and how it is inspected.

What Device Groups Control

Device Group Hierarchy

Device groups are arranged in a tree hierarchy of up to four levels. Lower-level groups inherit the settings (policies and objects) of all their ancestors.

graph TD
    SH["Shared<br/>(global — top level)"]
    L1["Level 1 Device Group<br/>e.g. All-Firewalls"]
    L2A["Level 2 — Region A<br/>e.g. EMEA"]
    L2B["Level 2 — Region B<br/>e.g. Americas"]
    L3["Level 3 — Site<br/>e.g. London-Office"]

    SH --> L1
    L1 --> L2A
    L1 --> L2B
    L2A --> L3

Inheritance rules: - A device group at level 3 inherits from its parent, grandparent, and great-grandparent (ancestors) - Inherited settings flow downward only — a child cannot push changes to a parent - Child groups can override inherited objects but cannot delete inherited policy rules

Prisma Access Predefined Device Groups

Prisma Access automatically creates one device group per licensed component:

All predefined device groups are children of the Shared device group by default.

📷 PaloAlto diagram — Prisma Access predefined device group structure

Rules for predefined device groups: - Do not delete the predefined device groups - Add your security policies inside the predefined device groups (or in Shared for policies that apply everywhere) - The Service_Conn_Device_Group must have parent = Shared — this is validated by Prisma Access during setup (see Chapter 27)

When to Add Custom Device Groups

Custom device groups are useful when: - Different branch regions need different security policies (e.g. EMEA branches vs APAC branches) - You want to create a regional sub-group under Remote_Network_Device_Group - Different user populations need different mobile user policies

Custom device groups are nested under the predefined groups, not alongside them — this preserves the inheritance of the Prisma Access predefined policies.

How This Maps in Strata Cloud Manager

Device Groups map onto Strata Cloud Manager's Folders concept — see Chapter 32 for the full explanation of how both Templates and Device Groups map onto Folders, and how Snippets differ from Template Stacks. This section covers only what's specific to Device Groups.

Hierarchy and inheritance: SCM Folders nest up to 4 levels below All Firewalls (confirmed in Chapter 32), and — like Device Group hierarchy — inheritance flows downward only. SCM surfaces this with a visual indicator: a grey dot marks a setting inherited from a higher folder, a blue dot marks one defined locally. A child folder can Override an inherited rule and later Revert it back to the inherited value — functionally the same downward-only, override-not-delete mechanic Device Groups use, just exposed through explicit Override/Revert controls rather than a blanket "cannot delete" restriction. (This mechanic was pieced together from several indirect sources rather than one authoritative page — reasonably confident, not fully verified against a single primary source.)

Predefined groups: the four predefined Device Groups above map onto the same predefined folder structure Chapter 32 already found for Prisma Access — including the Explicit Proxy nesting correction, which applies here too:

Master Device / User-ID group mapping: SCM handles this differently rather than mapping 1:1 — see the "Master Device" section below.

Master Device

Each device group requires a master device for Panorama to gather user group mappings (User-ID). The master device: - Is one of the managed firewalls assigned to that device group - Collects and redistributes user-to-IP mappings - Makes those user groups available when creating User-ID-based policy rules in the group

Strata Cloud Manager: there is no folder-level "one master device per Folder" equivalent. Master Devices are technically still supported in SCM/Prisma Access for the same narrow purpose (populating group-name dropdowns in policy rules), but SCM's recommended path is genuinely different: the Cloud Identity Engine handles user-group mapping instead, via Identity Redistribution (Configuration > NGFW and Prisma Access > Identity Services > Identity Redistribution > Redistribution Profiles), using a hub-and-spoke model scoped to an NGFW or NGFW Folder — not a single designated firewall per group. SCM does not translate "one Master Device per Device Group" into "one Master Device per Folder"; it replaces the whole mechanism with Cloud Identity Engine-based redistribution, with the legacy Master Device path still available as a fallback if Cloud Identity Engine isn't adopted.

Key Takeaways

• Device Groups control security policy and objects — Templates control network/device settings
• Hierarchy: up to 4 levels; Shared is always at the top; inheritance flows downward only
• Prisma Access creates 4 predefined device groups at onboarding — do not delete them
• Nested custom device groups allow regional or functional policy segmentation below the predefined groups
• Each device group needs a master device for User-ID group mapping
• In Strata Cloud Manager, Device Groups map onto Folders (see Chapter 32); Master Device has no direct 1:1 folder equivalent — Cloud Identity Engine + Identity Redistribution is the SCM-native path instead

Previous: Chapter 32 — Templates & Template Stacks · Next: Chapter 34 — Device Group Policies & Objects