Last updated Sep 10, 2025

How customers authorize AGC apps

If a customer requests to authorize an app, they will reach out to the app developer either through their contact page in the Atlassian Marketplace or through your partner manager contact at Atlassian. Some customers may be required to authorize apps as an external service, as defined in the FedRAMP Moderate SSP External Service addendum.

Each customer will approach app assessment differently, but many will have a template that they expect partners to complete for each requested app, and may require an additional call with the partner’s security team to further clarify the partner’s responses or ask additional follow up questions.

By purchasing and installing an app, customers will signal that an app has passed their assessment criteria and is authorized to operate in their Atlassian Government Cloud environment.

Preparing for app authorization

To help you prepare for AGC customer inquiries regarding app authorization, we've prepared an app authorization template. This template contains many of the details AGC customers request when assessing the security and compliance of an app:

App details	Description
External Service/System Name	State the name of your app.
System description/overview	Describe the business purpose and technology use-case of your app. Include a high-level summary of the in-scope user base and data processed.
External Service Type	State whether your app is: SaaS An external Vendor Service Corporate Shared Service
Data Ingress/Egress	Describe how data flows to and from beyond the AGC perimeter: Unidirectional incoming Unidirectional outgoing Bi-directional None
Authentication and Authorization	Describe how the service authenticates to the system (for example, User ID and password, API Key, SSH Key, Token, SAML Federation) Describe where the connection is originating from. (SaaS to Boundary, Boundary to SaaS). Note that vendors are inconsistent in their use of the term “API key”. It is often used as a stand-in for “tokens”, “codes”, “customer identifiers” depending on the product and usage. The following bullets cover the scenarios: Inbound: An external system uses an API key to communicate with the CSP Infrastructure/Platform API to obtain information about or data from the vendor resources. This scenario is only applicable to external systems requiring connectivity inbound to the CSP. Outbound: A CSP system uses an integration token to communicate with an external system. Sometimes the vendors refer to these as “API Keys”, but this is not an accurate description because they are simply a customer identifier. Sync: An external system uses an API key to communicate with another external system
Multi Factor Authentication (MFA)	Does the service connection require MFA? (Yes / No). If yes, which MFA vendor is being used and what is the mode of one time password (OTP) distribution (for example, voice, email, sms, push, authenticator app,)?
Role Policy (For Inbound / Bi-Directional Connections Only).	Provide permission sets and / or policies for any accounts associated with any inbound / bi-directional access. GSA needs to understand what can be changed or accessed as a worst case scenario if the accounts were compromised.
Key / Account Policies (For Inbound / Bi-Directional Connections Only)	Provide details on the account policies associated with any inbound / bi-directional access. This at minimum should discuss key storage / rotation practices and / or password refresh cycles as applicable
Role-based Access Control	Is Role-based access control implemented for integrated accounts? ( Yes / No)
Data Description	Describe the data content (for example, infrastructure metadata, user metadata, government data)
Data Categorization (Moderate Only)	Include a brief description of how this data was categorized (for example, FIPS 199, internal corporate processes)
Connectivity Method	Describe the app's connectivity (for example, web-based application or API, direct connection)
Connection Transport Security and Encryption	How is the connection secured (type of encryption and protocols used)
Encryption in Storage	Is the data encrypted at rest (Yes / No). If yes, what type of encryption is being used (for example, AES-256)? Are the encryption modules FIPS-validated?
Audit Logs Available	Does the external system provide the capability to generate audit logs that are available to the consumer? (Yes / No)
Level of Vendor Dependency	Describe the level of dependency (Low, Moderate, High) on the vendor regarding configuration of support and security control implementation. Include decision logic and how difficult it would be to migrate to an alternative if not approved for use
Alternative Exists	Does an alternate service exists which performs the same functionality? (Yes / No) If yes, describe the alternate service.
Traffic Source Role or DNS	What are the Source Roles & DNS names for the traffic flow?
Traffic Destinations Role or DNS	What are the destination Roles & DNS names for the traffic flow?
Inbound Ports & Protocols	What are the inbound Ports and Protocols to the System Boundary from the external service -- TCP/443 (HTTPs), TCP/22 (SSH)
Outbound Ports & Protocols	What are the outbound Ports and Protocols from the System Boundary to the external service -- UDP/53 (DNS), UDP/123 (NTP)