> 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-site-specific-key-ssk-vs-d.md). # Single beep troubleshooting Diagnose a single reader beep when a card is presented. This page covers how to identify whether your site is using a unique Site Specific Key, and how to revert to the default key if you have to. Reverting is not recommended for security. ### Symptom A T-series reader beeps once when a card is presented. No alarms or events are raised in Command Centre. There are no other indicators. Nothing shows in logs or the activity report. ### Causes A T-series reader single beeps when it detects a card of compatible technology but cannot read any information from it. There are several possible reasons. * The card is blank, so there is no information for the reader to detect. * The card contains a facility code that is not configured in the system. This is a legacy issue. * **The Gallagher object on the card is locked with a different key.** This is the most common cause on fresh vEL8.20 and above installs. ### Solutions * Blank cards must be encoded, or enable the **Use MIFARE Serial Number as Card Data** option. * Newer versions of Command Centre raise an alarm when an unrecognised facility code is detected. * Cards encoded with a different key need the troubleshooting below. Changes made in vEL8.20 mean a common cause of this issue is a fresh vEL8.20 or above install attempting to use pre-encoded cards supplied by Gallagher. Fresh installs of vEL8.20 and above use a Site Specific Key by default. If the site does not provide their SSK, Gallagher encodes cards using the default key. If the site key and the card key do not match, the cards will not work and the reader single beeps. ### Version behavior | CC version | Default key behaviour | | ----------------- | --------------------------------------------------------------------------------------- | | vEL8.10 and below | The default MIFARE site key is used by default. Sites can still choose to apply an SSK. | | vEL8.20 and above | An SSK is generated automatically on a fresh install. | | vEL8.30 and above | Key migration is introduced, so cards can be migrated from Default keys to an SSK. | > In vEL8.10 and below the field was called **MIFARE site key**. In vEL8.20 and above it was renamed **MIFARE key seed**. They are the same thing. ### Check whether a site uses an SSK Check the **Card Security** tab of Server Properties in Configuration Client. If the key seed field shows masked X characters rather than the Gallagher default value, the site is using an SSK. > **Important.** If the site license includes encoding, **do not proceed with key changes** without first establishing which cards have already been encoded with the SSK. Changing the key seed at this point may stop existing cards from working. Get more information about the existing cards and escalate to a senior or Technical Account Manager. ### Default-key cards received on an SSK site Use this when a site already has an SSK and has started issuing cards, then receives a new batch encoded with Default keys, for example because the SSK was not provided to Sales for that order. > **Important.** You MUST export the SSK before proceeding. 1. Export the SSK using **Export Keys…**. Choose a strong password, and keep the file and the password separate. 2. Create a Command Centre backup. This is optional but always a good idea. 3. Revert the site to the default key using **Set To Default**. This triggers a migration from SSK to Default. 4. Manually stop the migration from **Manage Card Migration**. ![SSK vs Default key troubleshooting step 16](https://328339335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6bM8WhlBE9BYizPWJaPN%2Fuploads%2Fgit-blob-0ecd3050422bf0d74a3070159e89fcae0223534a%2FSECHUB-CREDENTIALS-SSK-17.png?alt=media) 5. In the **DESFire default application key** field, manually enter the default Gallagher Default Application Key value. Retrieve this value from Configuration Client on a system that is running default keys. 6. The server is now using Default keys, and the new batch of cards will work. 7. Re-apply the original SSK using **Import Keys…**. This starts a new migration. 8. All cards **must** be badged at an HBUS reader. This migrates the Default key on the card to the SSK. Either badge all the cards at once, or configure the migration to last long enough that all of them will eventually be badged. 9. Once all cards have been badged, stop the migration. The site must still provide the SSK to Gallagher so that any cards encoded in future are encoded with the SSK. If that does not happen, the next batch of cards ordered will not work either. > **For vEL8.20 and below.** The only option is to revert the site to the default key. This is generally not recommended and a warning will display. The alternative is to return the cards to Gallagher for re-encoding with the SSK. ### Additional considerations Card types affected by key migration: | Card type | Migration behaviour | | -------------- | -------------------------------------------------------------------------------------------------------------------- | | MIFARE Classic | Unaffected. Classic card and reader keys are not changed during a migration, so Classic cards work before and after. | | MIFARE Plus | **Will not work after a migration.** MIFARE Plus cards cannot be migrated or re-encoded. They must be replaced. | | MIFARE DESFire | Keys are migrated. DESFire cards that are not badged during the migration will stop working when the migration ends. | Other situations that produce the same single beep: * The site provided an SSK, Gallagher supplied cards encoded with it, then the site reverted to the default key seed. The site key and card key no longer match. This is harder to resolve, because the original SSK has to be re-applied to the server. * The site moved from one SSK to another, and then possibly to a third. The result is the same: the site key and card key do not match, so the cards do not work and the reader single beeps. The only solution is to apply the key that was used to encode the cards. * Card sharing techniques that worked while all sites used the same default key will stop working once one or more of those sites starts using an SSK. *** 🔗 **Related** * [Credentials - Rolling keys on cards issued to a new site with a SSK](/knowledge-hub/products/cc-hardware/credentials/credential-information/credentials-rolling-keys-on-cards-issu.md). The procedure for a new site whose first card order was encoded with Default keys. * [Credentials - SSK Migration and the 2 Modes](/knowledge-hub/products/cc-hardware/credentials/credential-information/credentials-ssk-migration-and-the-2-mo.md). Choosing between an all-readers migration and a choke-point migration. * [Credentials - Fault Finding Cards with Site Specific Keys](/knowledge-hub/products/cc-hardware/credentials/credential-information/credentials-fault-finding-cards-with-s.md). The wider single-beep checklist, and Admin Cards for Cardax IV connected readers. --- # 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-site-specific-key-ssk-vs-d.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.