> For the complete documentation index, see [llms.txt](https://help.security.gallagher.com/knowledge-hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.security.gallagher.com/knowledge-hub/products/cc-hardware/credentials/credential-information/credentials-sharing-desfire-cards-betw.md). # Share DESFire cards between sites Share DESFire credentials between Gallagher sites by using supported key arrangements. This page covers how to share DESFire credentials between sites. Several options are described, with their limitations. ### Terms | Term | Definition | | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Original Card Issuer | The organisation that initially encodes the card. | | Secondary Site | A site that wants to use a card originally issued by a different organisation. | | Card Application | An independent entity on a DESFire card with separate access control, protected by its own keys. | | Default Application Key (DAK) | The value that the keys for a new card application are set to by default, before the application creator changes them to something more secure. Found in the Card Security tab of Server Properties in Configuration Client. If an Original Card Issuer is happy to let other sites encode independent applications onto cards they have issued, this is safe to share. | | MIFARE Plus / DESFire key seed | A value used as the seed to derive the keys that protect each card. Found in the Card Security tab of Server Properties in Configuration Client. | ### Choose a scenario ![Credential sharing scenario 1](https://328339335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6bM8WhlBE9BYizPWJaPN%2Fuploads%2Fgit-blob-986668dc0ab4fa44d0c9ed22e30718809d2a69bd%2FSECHUB-CREDENTIALS-SHARING-01-scenario-decision-tree.png?alt=media) ### Two Gallagher sites cannot share a MIFARE Plus or DESFire key seed ### Scenario 1a: the Original Card Issuer will share the Default Application Key, and the Secondary Site can encode cards 1. The Original Card Issuer copies the Default Application Key from the Card Security tab of Server Properties and shares it with the Secondary Site. 2. The Secondary Site creates a new Card Type with a new MIFARE DESFire object. ![Credential sharing scenario 3](https://328339335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6bM8WhlBE9BYizPWJaPN%2Fuploads%2Fgit-blob-cf8e464112e5fe839a16039bb3fe9472e37be601%2FSECHUB-CREDENTIALS-SHARING-03.png?alt=media) 3. In the Common Encoding Properties of the DESFire Gallagher Encoded object, reached by right-clicking the object, uncheck **Gallagher Issued** and enter the Default Application Key. ![Credential sharing scenario 4](https://328339335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6bM8WhlBE9BYizPWJaPN%2Fuploads%2Fgit-blob-74a6a2375cb322332d6ce65341bbe416f14065bd%2FSECHUB-CREDENTIALS-SHARING-04.png?alt=media) 4. The Secondary Site encodes cards using that card type. ### Scenario 1b: the Original Card Issuer will not or cannot share the Default Application Key, or the Secondary Site cannot encode cards This scenario is **not supported**. ### Both sites use the same MIFARE Plus or DESFire key seed The shared key seed may be the same by coincidence, or it may be one the Original Card Issuer was willing to share with the Secondary Site. > **Note.** Sharing the MIFARE Plus / DESFire key seed between different sites should only be done where there is a high degree of trust between them, for example where they are part of the same organisation. ### Scenario 2a: the Secondary Site can encode cards Encode the cards as normal. The shared key seed means the cards will work. ### Scenario 2b: the Secondary Site cannot encode cards The Original Card Issuer provides their facility code to the Secondary Site. The Secondary Site creates a new Card Type using that facility code. ![Credential sharing scenario 6](https://328339335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6bM8WhlBE9BYizPWJaPN%2Fuploads%2Fgit-blob-3200cf612611bf7d7411e7a1fdd9be80f89c407a%2FSECHUB-CREDENTIALS-SHARING-06.png?alt=media) The Secondary Site then uses that card type when adding an existing card to a cardholder. Because the data already encoded by the Original Card Issuer is being re-used, the card number entered must match what is already encoded on the card. ### Limitations * You **cannot** have two Gallagher objects on the same card that share the same Site Specific Key. This includes the Gallagher Default keys. * You **cannot** have the same facility code on a card under two different Site Specific Keys. *** 🔗 **Related** * [Credentials - Keys](/knowledge-hub/products/cc-hardware/credentials/credential-information/credentials-keys.md). Why the Default Application Key is safe to share, and the Site Specific Key is not. * [Credentials - Non Diversified DESFire object](/knowledge-hub/products/cc-hardware/credentials/credential-information/credentials-non-diversified-desfire-ob.md). Adding a separately keyed object for a third party system to read. * [Credentials - Site Specific Key (SSK) vs Default Site Key](/knowledge-hub/products/cc-hardware/credentials/credential-information/credentials-site-specific-key-ssk-vs-d.md). Why card sharing stops working once a site moves to an SSK. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.security.gallagher.com/knowledge-hub/products/cc-hardware/credentials/credential-information/credentials-sharing-desfire-cards-betw.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.