Skip to main content
Version 16.4 - 09/08/2026

Introduction

XBOX Requirements (XRs) consist of the policies, technical requirements, and product component-related requirements to which all developers and publishers of XBOX titles must conform. XRs ensure that products created for XBOX aren’t only stable and reliable but also provide a user experience that’s consistent, safe, secure, and enjoyable. Unless noted, all XBOX Requirements apply to all games certified as XBOX that ship on XBOX One, XBOX Series X|S console generations, xCloud, and PC.
  • XRs that are tested in Certification are identified with an asterisk (*).
  • For XRs tested in Certification, view the test cases here: XBOX Requirements and Test Cases.
  • For a summary of the changes in this release, see changes in this release at the bottom of this page.
  • To review the historical change log of XRs and test cases, see Change History for XBOX Requirements and Test Cases.
  • XR numbers aren’t contiguous. When an XR is retired, it’s removed from this page, and some retired XRs are folded into other XRs. For example, XR-129 (Intelligent Delivery content management) and XR-131 (Display mode support for Game DVR and screenshots) are retired, so this page has no separate Game DVR or screenshot requirement. If an XR number isn’t listed on this page, it isn’t part of the current requirements.

Base requirements

The requirements in this category apply to the general rules for the standards of coding, behavior of titles, and submission of titles.

XR-001: Title stability *

Titles must be compliant with Microsoft Store policies regarding title stability. The following policy applies to this requirement: 10.4.2
Products must start up promptly, continue to run, and remain responsive to user input. Products must shut down gracefully and not close unexpectedly. The product must handle exceptions raised by any of the managed or native system APIs and remain responsive to user input after the exception is handled.

XR-003: Title quality for submission *

XBOX games must meet XBOX quality standards and be fully functional and testable.

Functionally complete and testable

Titles must be fully functional and testable when submitted for certification. This includes all client code, submission artifacts, and downloadable content. Titles must be packaged cleanly with no failures using the current version of Submission Validator. Submission Validator logs must be included with the submission.

XBOX quality standards

XBOX games must function correctly across all game modes and scenarios to meet player expectations.
Title integrity
Titles must be free from severe issues such as crashes, freezes, unplayable frame rates, bugs causing major progression hindrances, or graphical corruption. Game settings, options, and controls must be applied correctly and respect default settings where appropriate. Navigation and content availability should be seamless, with no dead ends or inaccessible menus. Multiplayer functionality must be stable and functional, regardless of the number of players.
Save game compatibility
Game saves and player progress must continue to function following content updates. Additionally, permanent data loss must not occur when loading an updated save with the base disc version.

More information

Inaccurate and incomplete submissions will be rejected from Certification. Make sure to review the Submitting to XBOX Certification in Partner Center documentation prior to submitting for certification. For questions related to submitting to Certification, reach out to your Microsoft contacts.
Submission Validator
Submission Validator isn’t a standalone tool that the developer uses. Rather, it’s automatically called to check an app whenever the makepkg pack command is used. For more information about syntax and command-line use, see the makepkg reference page. The types of problems that Submission Validator identifies grow and evolve over time to work toward the goal of smoothing the way from submission, through certification, and to market. For the current list of problems that Submission Validator detects, see Submission Validator quality checks.
Partner-hosted services
Partner services that are required for the game to run must be functioning and properly configured when submitting to Certification. These services are verified prior to scheduling the title for test and must remain functional throughout Certification.

Implementation guidance and best practices

Options and settings
Game settings, such as options, controls, and languages, apply correctly when updated in game and after terminating and launching the title again. Default settings are respected where appropriate.
Navigation
All navigation commands must function as expected. On consoles, the game must be fully navigable with a controller. There are no dead ends in content, all game menus are navigable, and all content is available.
Localization support
There’s no requirement on the amount of localization a title must support. In areas where localized text is supported, the text must be legible regardless of the display setup.
Leaderboards
Titles must allow users to post statistics to all available leaderboards and sort those leaderboards using the filters provided.
Headset state change on console
On console, audio must continue to be heard when a headset is connected, removed, and re-connected. Refer to Comparison of XBOX One Software Development Kit and Microsoft Game Development Kit Audio API.

XR-130: XBOX Series X|S generation *

All game titles targeting a console generation must support the entire family of devices for that generation. To maintain consistency across console generations, games must:
  • Ensure that saved games work across console types within the generation.
  • Ensure that online players aren’t segmented based on console type within the generation.
  • Ensure that identical game modes are offered across console types within the generation.

XR-022: Official naming standards *

Titles must use the naming standards defined in the latest release of the Terminology List when referring to XBOX platform features, services, hardware, or peripherals. These standards apply to every XBOX game, regardless of the device it runs on. Titles must not display images of, or refer to, components of the device or its peripherals using terms that aren’t included in the terminology list.

XR-074: Loss of connectivity to XBOX and partner services *

Titles must gracefully handle errors with XBOX and partner services connectivity. Titles must honor the retry policies set by XBOX when attempting to retry a request to the XBOX service after a failure occurs. Titles must appropriately manage messaging the user when services are unavailable. If a partner service isn’t available, the game must not indicate that there’s an issue with the XBOX network. Titles must not crash or hang if network services are slowed or intermittently available.

XR-132: Service access limitations *

Titles that exceed title and user based limits when calling XBOX network services or don’t adhere to XBOX network service retry policies may be subjected to rate limiting, which may result in service interruption or deprecation. Failure to adhere to the specified limits may block a title from release, and in-production issues with released titles may result in XBOX network services suspension up to and including title removal.

Online safety and privacy

The requirements in this category pertain to the online safety and privacy of XBOX users.

XR-013: Linking Microsoft accounts with publisher accounts *

On XBOX, titles that use publisher-hosted services, publisher accounts, partner-hosted accounts, or other non-XBOX credentials must support a consistent, secure, and age-appropriate experience for XBOX users. If publisher account sign-in, account creation, or account linking is required for gameplay or game features, the title must provide an age-appropriate access path for all users who are eligible to access the title or feature based on:
  • the title’s age rating;
  • XBOX family, privacy, and safety settings;
  • supported regions where the title or feature is offered;
  • applicable local or regional laws; and
  • feature-specific privacy, safety, or moderation requirements.
Outside XBOX consoles, titles can choose whether to allow account linking to support their game experience. Publisher account sign-in If publisher account sign-in is enabled within the title, the following rules apply. Accommodate eligible users If a publisher account sign-in is required for game features, including single player, multiplayer, cross-network gameplay, leaderboards, cloud progression, user-generated content (UGC), or other advertised features, the title must support eligible user types, ages, and regions where the title is offered and where those features are allowed by local or regional law. A publisher can choose not to support a particular region, age group, account type, or user group for its standard publisher account. However, if that group of users can’t create, sign into, or link that account, the title must not require that account as the only path to gameplay or features that are otherwise available and legally permitted for those users. An acceptable access path can include:
  1. A standard publisher account that supports the user’s age group and region.
  2. A child or teen publisher account with age-appropriate defaults.
  3. A parental-consent or parent-authorized account creation flow.
  4. A cabined, limited, or privacy-preserving publisher account.
  5. A Microsoft or XBOX-authenticated access path that avoids unnecessary publisher account creation.
  6. A feature-specific fallback that lets eligible users access the feature without full publisher account linking.
If a particular account setting or user type isn’t supported in an in-title sign-up experience, the title must gracefully handle that scenario by directing the user to a supported external or mobile-optimized experience, or by providing another compliant access path. Disclosure alone isn’t sufficient if the title blocks rating-eligible users from core gameplay or advertised features that are otherwise legally available to them. Gain consent and provide terms for account information usage Titles must request and obtain consent before using information from the player’s Microsoft account to populate sign-up, account creation, or linking experiences. Users must be provided with all applicable terms of use, privacy statements, and other relevant policies within the title, or through a clear notice with a link to that information, during publisher account creation or linking. Disclose requirements If a publisher account is required for gameplay or additional features, that requirement must be disclosed in the title’s product description and any physical packaging. The disclosure must include material restrictions, such as age, region, account type, or feature limitations. In title, the game must explain the reason and use of the publisher account before requiring sign-in or linking. If a publisher account limits or restricts the experience for child or teen accounts, add clear Store detail language for buyer awareness. Example:
Certain features of the game, including online multiplayer, communication, user-generated content, cross-network features, or other online features, may not be accessible by XBOX child or teen accounts, or by users who don’t meet the publisher account requirements. Age and regional restrictions may apply.
Use title-specific wording when a known restriction applies. Example:
A [Publisher Account] age [X]+ is required for [feature]. Age restrictions apply.
Publisher account and Microsoft account linking Authentication using the XBOX Secure Token Service (XSTS) XSTS tokens must be used to provide identity information for authentication when linking a user’s publisher account to the user’s Microsoft account. For more information about XSTS token authentication, see XBOX services authentication for title services. Titles must authenticate both the Microsoft account and the publisher account before establishing the link, and must not link accounts using unauthenticated identifiers such as Gamertag alone. Use the Partner XUID (PXUID) or pairwise identifier for account linking. Don’t use the XUID for account-linking storage unless it’s explicitly required for an approved service-to-service scenario. Gain consent and provide choice Users must be notified when their publisher account is linked to their Microsoft account, and must be given a choice to opt out when account linking is optional. Users must have the ability to de-link accounts. Account unlinking can be provided in title, on the web, in a companion app, or through another dedicated account-management experience. Accommodate eligible users for linking If publisher account linking is required for gameplay or game features, linking must support eligible user types, ages, and regions where the title is offered and where those features are allowed by law. If a linked publisher account is required but the publisher can’t support a user’s age group, region, or account type, the title must provide an approved alternative access path or request an exception. Age and account handling Before offering account creation or linking features to a Microsoft account user, titles must validate the user’s age group by calling XUserGetAgeGroup. Titles must handle the following account categories correctly:
  • When a user’s Microsoft account age and publisher account age differ, the title or service should apply the more protective treatment, unless another legally compliant approach (such as an approved age verification platform) is used.
  • For child accounts, publishers must obtain parental consent before creating an account where required by law. Parental consent, including acceptance of publisher terms and privacy statements where required, must be provided through the publisher’s compliant account flow, not assumed from XBOX network participation alone.
  • For teen accounts, publishers must provide clear information about social, UGC, communication, data-sharing, and privacy-impacting features. Where appropriate, publishers should ask teens to notify a parent or guardian that the account has been created.
  • If the publisher collects age during account setup and determines that the user doesn’t meet the publisher account requirements, the publisher should stop account creation before collecting unnecessary personal information, inform the user that they can’t continue, prevent immediate re-entry of different age information where appropriate, destroy personal information already collected that isn’t necessary to retain, and avoid repeated failed sign-up or linking attempts.
Publishers are responsible for complying with all applicable privacy, child-safety, consumer-protection, and age-assurance laws in every country or region where their products and services are offered. Feature-specific restrictions Publishers can restrict, disable, or require additional consent for specific higher-risk features when necessary for safety, privacy, legal, moderation, or age-appropriate design reasons. Examples include:
  • voice or text chat;
  • friend systems or social graph features;
  • cross-network communication;
  • UGC upload or publication;
  • public profiles;
  • external forums or community features;
  • purchases, premium currency, or monetization; and
  • behavioral advertising, profiling, or optional data sharing.
Where possible, publishers should separate higher-risk features from lower-risk gameplay access. For example, requiring a publisher account for UGC upload can be acceptable while still allowing eligible users to browse, download, or use curated or moderated content without the same account requirement. Unlinking Users must have the ability to unlink publisher or service accounts from their Microsoft account. Titles should give users full control of account linking, unlinking, single sign-on, parental-consent status where applicable, and review of applicable terms and privacy policies. Unlinking options must not be hidden deep in the UI or require technical support as the only available method. Single sign-on Titles must implement single sign-on after an account link has been made. After linking, the title should automatically sign the user into the linked publisher account on XBOX consoles without requiring the user to repeatedly enter publisher credentials. Titles must not store non-XBOX account credentials or unnecessary personal information locally on the console.
[!NOTE] Publishers can implement additional fraud-prevention mechanisms, such as two-factor authentication when a linked account signs in from a new device for the first time. This behavior isn’t a violation of this XR.
Exceptions If a publisher can’t provide an age-appropriate access path for rating-eligible users, the publisher must request a title-specific exception. Approval for one title doesn’t create blanket approval for future titles. The exception request must include:
  1. The affected title, rating, platforms, regions, features, and user groups.
  2. Whether core gameplay remains available without a publisher account.
  3. Which features are blocked or limited, and why.
  4. The legal, privacy, safety, technical, or moderation basis for the restriction.
  5. The proposed Store, packaging, and in-title disclosure language.
  6. The user experience for blocked or limited users.
  7. The test plan for child, teen, adult, family-managed, and region-specific account cases.
  8. Any mitigation plan or roadmap to support age-appropriate access in the future.
Exceptions should be time-bound or reviewed for future releases when the restriction affects core gameplay, multiplayer, or prominently marketed features.

XR-014: Player data and personal information *

Game publishers are solely responsible for collecting and processing end user data in accordance with applicable law especially when the user is a child. Additionally, when a title has information about a player either acquired from XBOX or from their relationship with the player directly (such as a website or mobile app), titles must not display to other players:
  • Information that could be used to cause financial damage to a user (such as Social Security or credit card numbers).
  • Information that divulges a user’s address beyond country/region.
  • Information that would allow a user to impersonate another user online, such as account credentials.
Handling Child Data
When collecting data from accounts in the Child or Teen Age Group, titles may only request personal data necessary to verify age, obtain parental consent or complete publisher account linking.
[!Important] The request for data must state what the data will be used for. For example, if a title asks for a user’s birthdate it must state what the birthdate will be used for: Good Examples:
  • Please provide your birthdate so we can verify your age
  • Please provide your birthdate so we can personalize your experience
  • We need your birthdate to offer age-appropriate content
  • We need your birthdate to comply with legal age restrictions
Bad Examples:
  • Please provide your birthdate
  • Enter your birthdate
  • We need your birthdate
  • Birthdate required
Definitions
Address is any information that can identify a user’s location to the level of city or town. This includes, but isn’t limited to, the following:
  • Physical address
  • Mailing address
  • Billing address
  • ZIP code
  • IP address or related information
  • Geographical location information

XR-015: Managing player communication *

Titles must not allow communication over the XBOX network when the user’s privacy settings don’t allow it. Titles meet this XR by retrieving data from XBOX network services. If the title uses its own services, it must check the user’s privacy permissions at the beginning of a session or when a new user joins the session. For user-initiated scenarios outside of sessions, titles meet this requirement by checking privacy before displaying the user’s data and before performing the action. The following permissions are available for titles to check: During the gameplay session, titles which offer communication between XBOX network and non-XBOX network players must offer the ability to mute any non-XBOX network players for the duration of the session.
[!Note] Refer to Privacy and permissions overview for details on how to check and resolve privacy and permissions issues in your title.

XR-018: User-generated content *

User generated content (UGC) refers to any in-game digital content produced by a player and made visible or accessible to one or more other people in an online state. If your product contains UGC, you must:
  • Provide an in-product means for users to report inappropriate or harmful UGC to the developer for review and removal/disablement (if in violation of content guidelines) and/or implement a method for proactive detection of inappropriate or harmful UGC (for example, text filtering).
  • Publish content guidelines for user generated content (such as a terms of use or code of conduct), available to users either in-product or on the title’s website.
  • Be prepared to remove/disable high-risk illegal content at the request of Microsoft in the unlikely event that Microsoft becomes aware of illegal material on the XBOX network that hasn’t been addressed via standard action mechanisms or processes.
  • Respect player UGC settings and gracefully handle scenarios in which a user doesn’t have access to UGC in-game due to restricted privileges.
Additionally, if your product is integrated with a third-party game mod platform, you must:
  • Integrate with the platform’s report/complaint API (if available) and moderate content if required by contractual agreement with the third party.
  • Present a disclaimer, dialog, or visual indicator to users when content isn’t sourced from the developer.

Content packages and updates

The requirements in this category specify how games must be packaged and how they must interact with add-on content packages.

XR-037: Dependencies on content packages *

Purchase of add-on content (durable or consumable) must not be required for users to complete any of the main features or content of the base game. Optional content packages must not have dependencies on other optional content packages. That is, a user must not be required to download additional content packages in order to use a content package. Game saves with unique content tied to add-on content must still load on the base game or provide clear messaging explaining why it can’t be loaded.

More information

The key aspects of this requirement are:
  1. Users must not be required to purchase add-on content to complete the main features of the base game.
  2. Users must not be required to purchase additional add-on content to use another content package. Add-on content must be usable independently from other add-on content.
  3. Game saves with unique content tied to add-on content must still load on the base game or provide clear messaging explaining why it can’t be loaded. As a best practice, the messaging should include a prompt to download the content if already owned or prompt the user for potential purchase if not owned.
  4. Titles that support add-on content required for multiplayer gameplay must provide clear messaging to users who don’t have the content installed.

Implementation guidance and best practices

Ideally, games gracefully handle the situation where the user previously played with add-on content that’s now removed and let the user load and continue from their game save. If this isn’t possible, games must clearly message the user, indicating that the content needs to be installed to load the game save. Titles can query to see whether the user has an entitlement to that content and either:
  1. Prompt the user to download the specific content if already owned.
  2. Prompt the user for potential purchase of that content if not owned.

User profiles

The requirements in this category apply to how a game interacts with the XBOX user models, profiles, and saving user data.

XR-112: Establishing a user and controller during initial activation and resume *

Titles must establish one or more active users to function as the primary user or users in the title, and handle the user or users when resuming from suspension, sleep, or hibernate. Titles do this with the GDK by using either the Simplified or Advanced User Model. GDK Simplified User Model titles The Simplified User Model in the GDK handles default user acquisition on behalf of the title. The title is still responsible to ensure that a controller is assigned to the user and use that controller for game input. If no controller is assigned to the default user, the title should use XUserFindControllerForUserWithUiAsync to engage the system dialog to select a controller and begin accepting input from the player. GDK Advanced User Model On initial activation games can choose to determine the initial user based on their game design and preference using either the user who launched the title or by explicitly prompting for a user. The title must indicate the active user(s) before the first profile-related action (such as saving progress or settings) is taken on that user’s profile. All Microsoft Game Development Kit (GDK) titles using the advanced user model must provide an entry point to the account picker to change the active user. When a title is resumed from suspension, sleep, or hibernate, the title must validate the user/controller pairing and react accordingly by resuming the prior user’s session or acquiring a new user or users.

XR-115: Addition and removal of users or controllers during gameplay *

Titles which support multiple users must respond to the addition and removal of users or scenarios in which an active player has no controller assigned or a controller loss during gameplay as follows: Controller Addition: After the title selects or receives the initial user and controller, it can optionally accept input from other controllers. Titles that support multiplayer experiences should consider how an additional player or controller is added into game play and is bound to a user with XUserAddAsync. For example, ‘Press A to join’ or illustrating a controller silhouette on a player select screen. Controller Removal: If the player’s controller that’s driving gameplay is removed during gameplay, titles must allow reestablishment of a new active controller (for example, “Press A to continue” or receiving a ControllerPairingChanged in ERA or XUserDeviceAssociationChangedCallback event in the GDK for the active user with a valid controller). Titles can also invoke system UX using XUserFindControllerForUserWithUiAsync to prompt the user to pair a controller to their user and return to gameplay. User Addition: When using the GDK (using either Simplified or Advanced User Models), users are only added when the title calls XUserAddAsync. Primary User Removal: For titles using the GDK advanced user model, if the primary user is signed out (via the guide, SPOP or other means), the title must either remove the player from the game or reestablish a user and active controller. For titles using the GDK Simplified User Model, the primary player being removed results in the title being suspended at the system level. In all scenarios, titles handle removal/closure by placing their game in a good state. This includes writing to connected storage, notifying any relevant MPSD sessions that the user left, and bringing the user to an appropriate place for sign-in if no new user was added. Additional/Secondary User Removal: Titles can handle this event in their discretion, usually by removing the player from game play immediately or prompting the player to rejoin in the context of the multiplayer experience being used.

XR-045: XBOX network and account privileges *

XBOX network provides users with an expected level of privacy and online safety for themselves and their children. In order to deliver on that promise, titles must check the XBOX network service for privileges to complete certain actions on the XBOX network service or in a title experience. While privilege checking and adherence applies to all accounts, it’s important to note the experience and expectations for child accounts specifically. For child accounts, restrictions on certain activities may be blocked due to age-based defaults and/or configurations by the child’s family organizer (parent or guardian). Children can’t make changes themselves, however, with certain activities it’s possible and expected the title invokes the necessary system UI to allow young players to request an exception via an approval flow for that associated activity. In such circumstances, for instance, a young player may be blocked from multiplayer globally, but the family parent or guardian could approve multiplayer for the specific title via the system UI; then the child would and should be able to access this game mode for that specific title. Free to play titles, demos, or betas can be configured to allow multiplayer gameplay (ID 254) for players who aren’t XBOX Game Pass subscribers. This is done via a service side configuration and can be initiated by contacting your Microsoft representative. These titles must continue to check for the multiplayer game privilege to ensure that parental controls and player choices are respected.

XR-046: Display name and gamerpic *

On XBOX consoles, titles must use the gamertag as their primary display name. Based on design choice, titles can choose between the player’s modern gamertag or their classic gamertag. Modern gamertag is available in the GDK and classic gamertag is available in both ERA and the GDK. On non-console platforms, while not required, we recommend you use the XBOX network player’s gamertag in the appropriate locations within the game title’s experience. The gamertag must be displayed correctly in the title based on the gamertag type used: Modern Gamertag
Display all 16 characters of the unique modern gamertag, which includes up to 12 characters of the modern gamertag, followed by # and the suffix number (if present). For example: Major Nelson (no suffix present) or Major Nelson#881. If modern gamertags are used, all Unicode character ranges available for modern gamertags must be supported. For more modern gamertag information and best practices, visit the GDK development documentation article ‘Overview of modern gamertags’.
Classic Gamertag
Correctly display all 15 characters of the classic gamertag. Classic gamertags include only ASCII characters a-z, A-Z, 0-9, comma (,), and space (ASCII character 0x20). For example: Major Nelson
In the GDK, these items are returned using the XUserGetGamertag API. In ERA, the gamertag is obtained using the GetUserProfileAsync API.

XR-047: User-profile access *

Titles must give users the option to access other XBOX network users’ gamercards (user profiles) wherever users’ display names are enumerated.

XR-048: Profile settings usage *

The XBOX network is the source of truth for XBOX user profile information. To support this, titles must not store users’ information sourced from the XBOX network, such as profile data, preferences, or gamertags, beyond a locally stored cache intended to support scenarios of network disconnection. Any offline caches must be updated upon the next available connection to the service.

XR-052: User state and title-save location, roaming and dependencies *

Titles must associate progress, saved state, preferences, achievements, and other rewards with the user(s) who recorded that progress, chosen the preferences, or earned the rewards. Titles accomplish this by properly handling user-change notifications. Titles must avoid saving state for users who are no longer signed in. Game save data must not have any dependencies on shared content or local storage. For games that use the same TitleID across platforms, devices and/or console generations, game save progress must roam when the user is signed into the XBOX network as follows:
  • Within the same platform (XBOX consoles).
  • Within devices on the same platform (for example, XBOX One and XBOX One S).
  • Across generations in the device platform (for example, XBOX One and XBOX Series X|S).
  • Across PCs in the Windows platform (for example, between two different PCs).
  • If the game is XPA, across PCs in the Windows platform and XBOX console platforms (for example, Windows and XBOX Series X|S).
  • For non-XPA games, roaming across PCs in the Windows platform and XBOX console platforms (for example, Windows and XBOX Series X|S) isn’t required but is recommended to support the player’s experience.
  • For non-Microsoft platforms (for example, iOS, Android, Switch, PlayStation®) game save roaming isn’t required but is recommended to support the player’s experience.

Achievements and awards

The following requirements apply to titles that offer achievements on the XBOX network. All games targeting XBOX consoles are required to have Achievements and meet the following requirements. Demos aren’t allowed to have achievements; however, they have the option of supporting Hero Stats.

XR-055: Achievements and gamerscore *

Titles must provide the required number (minimum and maximum) of achievements and their associated gamerscore at launch. Titles are permitted to add achievements or gamerscore at any time after launch, with or without corresponding new content, but they can’t exceed title-based or calendar-based limits. A single achievement can’t exceed 200 gamerscore and all achievements in the title must be achievable. Unlocking achievements in the base game or a content update must represent a thorough exploration of or engagement with game content. Note: “Semi-annual” means January-June, July-December. Base game achievements and Gamerscore don’t count towards the semi-annual limits. Achievements must not be shared across titles. When a single title is supported across different devices by using the same title ID, the title must share the same set of achievements and can, at its discretion, have device-specific achievements. Achievement names and descriptions may contain only content that would merit a rating of PEGI 12, ESRB EVERYONE 10+, or lower. Achievement names and descriptions may not contain what is commonly considered profanity in a clear text or redacted form.

XR-057: Unlocking achievements *

Titles must provide a way for a user to earn all achievements defined by the base title without being required to purchase additional in-title content. Achievements must be unlocked through in-game actions, gameplay, and/or experiences. Titles must not provide players alternative options that unlock achievements directly without corresponding gameplay activity. A non-exhaustive list of disallowed options:
  • A real-money purchase
  • In-game cheat codes, consoles, or menu options
These options may be used to reduce the difficulty of the gameplay required to unlock achievements. After an achievement has been published to users, it can’t be removed, nor can its unlock rules or rewards be changed. Achievement text (name and description) and art (icons and background) can be modified.

Multiplayer sessions

The requirements in this category pertain to game titles that provide multiplayer sessions on XBOX. XBOX offers a consistent and simple way to find multiplayer sessions and to fine-tune the parameters used to find those sessions.

XR-064: Joinable game sessions and online play *

Titles that offer joinable game sessions must advertise joinability to the XBOX network through the Multiplayer Activity (MPA) feature, so players can join from XBOX surfaces such as the guide, a friend’s profile, and Game Bar. Titles that offer an in-game invite mechanism are recommended to route those invites through the XBOX platform so recipients receive them through the XBOX shell.

XR-067: Maintaining Recently Played With interactions *

Titles with online multiplayer functionality must record meaningful player interactions on the XBOX network by using the Multiplayer Activity (MPA) Recent Players feature, so the platform can surface the Recently Played With list, player feedback, and usage reporting. Titles still using the legacy Multiplayer Session Directory (MPSD) may instead maintain session-state information in the MPSD, but must not use both.

XR-070: Friends lists *

Titles must use the XBOX network Friends list as the primary list of friends. Titles must obtain the friends list from XBOX APIs and must not store the friends list in a permanent nature on game servers. Titles can display a secondary list of friends from a central title account for players not on the XBOX network or not on the user’s XBOX network friends list. Based on design, titles may create a blended friends list experience containing both XBOX network and publisher account friends in a central location; iconography or other clarifying marks must be used to disambiguate XBOX friends from those on other networks. For information on using the friends list using the GDK, read the People System (Friends List) overview

Betas and Game Previews

The requirements in this category apply only to titles classified as betas or Game Previews. For other store policies and for program-specific definitions of open and closed betas, size limitations, duration, pricing, metadata, and offers, see the XBOX Game Store Policy(1. XBOX Store and Digital Distribution, 2. XBOX Store Policy). Beta and Game Preview titles are subject to a subset of the XRs presented in this document. The scope of this subset is detailed in the XBOX Requirements for Game Previews and Betas page.

XR-117: Beta/Game Preview notification *

Titles that are in beta stage must have a splash screen or message that’s displayed within the experience, after it’s launched but before gameplay or application usage, communicating that:
  • The title is beta/pre-release software.
  • Some platform features might not work correctly.
  • Some game features might not work correctly and might crash.
The notification must also outline the support boundaries for the title.

Changes in this release

Last modified on October 20, 2026