Bluetooth Low Energy (BLE) is a wireless network technology that is often used in IoT scenarios like indoor navigation, proximity marketing, automatic check-in or contactless payment. These usually use broadcast messages, so called BLE beacons, which by default have no protection mechanisms against attackers. Anyone with a Bluetooth receiver device can see these beacons and their content and thus can copy, manipulate and replay them anywhere at any time [3]. Therefore no confidential data should be transmitted using beacons. Furthermore location determination and authentication based on beacons is not to be trusted.Common beacon developers like Google(1), kontact.io(2), and Estimote(3) use UUID shuffling to defend their beacons against such attacks. This means that the beacon UUID is shuffled depending on a seed and a shuffling algorithm. The seed and the algorithm are to be kept in the cloud and the beacon only to ensure attackers cannot gain any knowledge by reverse engineering the corresponding app. This setup brings two problems: (a) a constant cloud connection is required to decode beacons and (b) keeping the shuffling algorithm secret is security by obscurity and therefore cannot be trusted [2].We present a solution to defend BLE beacon applications against common attacks like manipulation, data extraction, replay, and cloning attacks. There are two main results: (a) a structure for BLE beacons that protect the confidentiality, integrity and authenticity of the payload and (b) a prototype infrastructure, which fulfills all the preconditions needed to achieve (a). Our beacon relies on well researched cryptographic primitives such AES encryption, which today is supported in hardware by commodity low-energy BLE chips, SHA256 hmac and Curve25519 [1]. Additionally no constant cloud connection is needed to decode beacons.To test our secure beacon we developed prototype Android application, which receives theses beacons from a microcontroller. The payload consists of arbitrary data that is AES-encrypted and also provides integrity checks and replay protection. The disadvantage in this version is the usage of a shared key for encryption. The key must be available on the Android device on startup, which means it has to be hardcoded in the application. To solve this problem, we extend our prototype in a second version by a registration phase. Before sending beacons, a beacon device must register itself to the system. This registration process is protected using the asymmetric authentication protocol ISO/IEC9798-3 extended by a public key infrastructure (PKI) and key exchange using elliptic-curve Diffie-Hellmann.We show how beacon protection can be achieved and proposes to standardize a format for secure beacons.