The count on the invoice should match the people who work here.
Guard is the org-level layer that holds single sign-on, SCIM provisioning, authentication policies, and the controls that apply across every Atlassian product in the estate. Our work is SSO, SCIM provisioning, authentication policy, permission design, and the cleanup that makes the user count defensible.
Guard carries single sign-on, directory provisioning, and authentication policy across the Atlassian estate. We design that model, clean up what has accumulated, and produce the evidence a review asks for.
What it is
Guard is the org-level layer that holds single sign-on, SCIM provisioning, authentication policies, and the controls that apply across every Atlassian product in the estate.
It is for organizations that already run an identity provider and need Atlassian to obey it, rather than to maintain a second, quietly divergent list of who has access.
What it does
Single sign-on across the estate
Authentication moves to your identity provider, so leaving the company actually removes access.
Directory-driven provisioning
SCIM group synchronization means joiners, movers, and leavers change access without a ticket.
Authentication policy by population
Employees, external vendors, and service accounts can be held to different rules rather than one compromise.
Evidence for review
Who holds what, and who approved it, becomes a report rather than a meeting.
Where it fits
L1, identity and access. This is the bottom of the Stack, and everything above it inherits whatever it decides. A migration, a service desk, a portfolio roll-up, and an agent rollout all resolve access through this layer, which is why a gap here is never contained to this layer.
What we do with it
Design and implement the identity model
SSO, SCIM, group structure, permission schemes, and the review cadence, designed once and applied across the estate.
Cleanup and true-up
Reconciling licensed users against actual users, and putting the accounts nobody can explain in front of an owner for a decision.
Identity inside a migration
Access decided before anything is copied, so users land where they belong instead of arriving as they were.
Access as an operation
Access requests, group changes, and recurring reviews run continuously rather than as a project that ends.
Where it earns its place
A carrier standing up new squads
New projects need group-based provisioning from the first day, or the permission exceptions start immediately and never stop.
An organization after a Data Center migration
A licensed count that exceeds headcount is the usual finding, and it is a licensing conversation and a security one at the same time.
An estate with external vendors in it
Vendor identity carried on group attributes is the difference between a policy you can enforce and one you can describe.
Proof
Machine identities per human in the enterprise, up from 45:1 two years earlier.
Palo Alto Networks, 2026 Identity Security Landscape, 2,930 respondents. Earlier ratios: CyberArk Identity Security Threat Landscape, 2024 and 2025.
Organizations that had a successful identity-related breach in the last twelve months.
Palo Alto Networks, 2026 Identity Security Landscape, 2,930 respondents.
Of security leaders worry about excessive access held by non-human identities.
Okta Global CISO Insights, 2026.
Questions we get
We already have Okta. Does Guard duplicate it?
Is this a licensing purchase or a project?
What usually turns up in the cleanup?
How long before it is defensible?
Licensing
Guard is licensed against your user count, which is exactly the number the cleanup tends to change, so the audit is worth running before the renewal rather than after. That reconciliation sits with the rest of the estate in licensing and renewals.