Tutorial: How to Make Your Beacons Fully Secure with the Proximity Web Panel Secure just launched, so starting from today, you can shuffle your beacon identifiers and encrypt all beacon communication to make your beacons secure from any kind of attack. If you want to dive deeper into how it works technically, we recommend reading our Beacon Security FAQ. This guide will show you how to turn Secure on and how it will affect other API and Web Panel features. Ready to take your beacon security to the next level?

What is Secure? Secure is the only complete suit of technology that protects your beacons against any kind of beacon-related attack. Basically, it consists of two new sets of features that are based on two rules:

  • no device understands what is being communicated to a beacon other than the cloud platform and the beacon itself ( Secure Communication)
  • anyone who captured your beacon identifiers in the past can no longer use them because they change repeatedly ( Secure Shuffling)

There are two conditions that you need to meet to start using Secure:

  • Secure brings a major change on the hardware’s side, so you need to update your beacons to the latest firmware (4.0)
  • All communication is encrypted and only our cloud can decrypt it, so using our API and/or SDK in your iOS or Android app is required if you’re going to configure a beacon
  • (optionally) if you turn on Secure Shuffling, the only way to deshuffle the pseudo-random identifier that your beacon is broadcasting and extract the original identifier that your application is expecting is to use our SDK or query our API. If you have shuffling enabled, your app must include our SDK or your own homebrew connection to the Proximity API or else your application will not function!
    • Note that you can cache 7 days’ value of shuffled IDs on a mobile device’s local storage ahead of time, so realtime Internet access doesn’t have to be guaranteed in order for shuffled beacons to be resolved by a device.

Here’s how to turn it on using Proximity Web Panel.


Update your firmware to 4.0 in Web Panel

4.0 is available to beacons running on v3.1, so if you’re using an older version of our firmware, please update it to 3.1 first. You can check and update the version of your firmware in the Proximity Web Panel.


Select a device that you want to update and click on UPDATE FIRMWARE in the additional information section.

Web Panel will ask you to confirm that you want to update your beacons. This is because firmware 4.0 fundamentally changes how your beacons communicate with devices that manage them. If you use’s tools (Web Panel, Admin Apps, API, and SDKs) to manage your infrastructure, this update won’t change anything. But you won’t be able to update and manage your beacons if:

  • you use a custom admin app—unless you update it to the latest Proximity SDK
  • you use a custom proximity management platform that isn’t built upon our API (or isn’t synchronized with the latest version)—unless you integrate it with our API

If you update your devices to firmware v4.0, you can’t downgrade them. Make sure you have your environment ready before you confirm the update. Don’t push these updates to a live environment until you’re positive that your app works with the new features.
For the moment, bulk updating beacons to the newest firmware is disabled to prevent accidentally deploying to and screwing up entire beacon fleets. We will add this functionality back in for firmware 4.0 in the near future.

If the update is performed by a user with ADMIN or OPERATOR permissions, the SUPERUSER will automatically receive a message from the Proximity Web Panel.

Update your beacons in the iOS Admin App

Having confirmed the update in your Web Panel, launch your iOS Admin App (the feature will be available for Android users soon) and deliver the update to your beacons when you’re in range.

Enabling Secure Shuffling Secure Communication is mandatory in firmware 4.0. Optionally, you can turn on Secure Shuffling which will shuffle your beacon’s uniquely broadcast information every 24 hours. That means that your app will stop understanding your deployed beacon’s signals unless they’re built upon the most recent Proximity SDKs.
You can enable shuffling in your Web Panel (in the security section) and then apply your created configuration in the Admin App, or you can go directly to the Admin App and do it in a device’s configuration:

Once shuffling is on, you’ll see the current shuffled identifying information and a list of the 7 future ones in your Web Panel.

It’s possible for your beacon’s shuffling algorithm to become desynchronized with what the Cloud API. This will usually only occur if a beacon’s battery is not connected or has died. If this happens, you will need to disable shuffling, connect to the beacon to turn shuffling off, and then re-enable shuffling. While the Cloud API will always resolve a beacon’s shuffled identifier into the original values, you may find that the if you have stored the next value to a local cache it is not enough to be 100% sure that a shuffled beacon will be resolvable.

Shuffling iBeacons and Eddystones

There are several shuffling methods already published out there, but none of them are without their flaws, including OS-level bugs which can make security challenging to develop. Our own implementation doesn’t shuffle every singly value of the beacon because it’s not necessary and because it can cause problems with phone OSes. Here’s a breakdown of what is shuffled when you advertise in iBeacon or in Eddystone format.
Beacons advertising  iBeacon profile: shuffle Majors, Minors, and MAC addresses but you can’t shuffle Proximity IDs. As long as your beacons are being shuffled, you also won’t be able to change their Proximity IDs manually (you can see in the screenshot below that Web Panel disables this field.) If you need to update this value, turn shuffling off, adjust the Proximity ID, and turn shuffling on again.

Beacons advertising  Eddystone format MAC address is shuffled as well as Instance ID. You can’t shuffle or change Namespace IDs (turn shuffling off for a moment to update this value.) Also, keep in mind that Eddystone-URLs don’t work with shuffling.
You can still switch between iBeacon and Eddystone on shuffled beacons.
Please note: Values you can see and update via our Web Panel and API are the values you use in your app, not the values that your beacons are actually broadcasting. That’s the whole point: beacons shuffle the real identifiers, your app grabs them, unshuffles them with our SDK or API, and then performs the assigned actions. So if you see a beacon broadcasting different Major and Minor that the ones you entered in your Web Panel after you’ve turned shuffling on, don’t panic—that’s exactly what you want to do 🙂

Sharing shuffled beacons

You can still assign and reassign shuffled beacons with people within your user structure. You can also share your beacons or venues with shuffling turned on (just make sure the external apps using your beacons are up-to-date with the most recent version of’s SDK.) When shuffling is on, you can’t move beacons to users outside of the company.

The people with whom you’ve shared your devices without specifying the expiration date will see the current and seven future IDs of the shared beacons in their Web Panel accounts (just as you see them in yours.) If you specified the sharing expiration date, and their sharing permissions expire in less than eight days, they’ll see as many future IDs as as they have days left until their permissions expire.

Shuffling when beacons are off

If a shuffled beacon doesn’t broadcast a signal for more than 24 hours—because you removed the battery, or because it drained—we recommend that you turn shuffling off and on again to synchronize it so that if you’re caching values in advance of the change, you will have the correct values pulled into your app. If you don’t shuffle the beacon, the API will still be able to resolve the deshuffled values, but you’ll need to query our Cloud every single time you want to deshuffle it, and that’s not exactly convenient or fast in all applications.
This is because once the beacon wakes up, it starts broadcasting its shuffled IDs starting from the most recent one it transmitted. Since the API’s shuffling algorithm advances inexorably whether a beacon is broadcasting or not, the cached values will grow increasingly out of sync between the app (which is syncced with the cloud) and the beacon (which is not).
If you don’t synchronize the beacon, it’ll keep broadcasting, and your apps will keep working but API won’t show you next shuffled identifiers.

Contact us