Abstract-DTLS is becoming the de facto standard for communication security in the Internet of Things. In order to run the DTLS protocol one needs to establish keys between the communicating devices. The default method of key establishment requires X.509 certificates and a Public Key Infrastructure, an approach which is often too resource consuming for small IoT devices. DTLS also supports the use of pre-shared keys and raw public keys. These modes are more lightweight, but they are not scalable to a large number of devices.We present Scalable Security with Symmetric Keys (S3K), a key management architecture for the resource constrained Internet of Things. S3K provides a flexible and scalable way of establishing keys between resource constrained IoT devices. S3K enables devices that have no previous, direct security relation to use DTLS with either pre-shared symmetric keys or raw public keys established and authorized during the DTLS handshake. We implement S3K in the Contiki OS and evaluate it on real IoT hardware. Our evaluation shows that S3K is feasible in constrained environment and at the same time scalable to a large number of devices.Note to Practitioners: Key management is one of the hardest problems in cyber security. It is even more challenging in the Internet of IoT considering that most things are resourceconstrained. Therefore, IoT devices either end-up using the symmetric cryptography with pre-shared key mode or asymmetric cryptography with raw public keys (RPK) mode. These modes either require a pre-provisioning of all expected trusted clients in individual nodes before deployment or requires outof-band validation of RPKs. Also, if the number of clients that a node would communicate with varies dynamically, this would demand frequent re-provisioning of each trusted client to the individual nodes. The approach based on preprovisioning and re-provisioning of trusted keys is certainly not scalable and requires a continuous management of security policies. We therefore propose a solution that is scalable and does not require pre-provisioning or re-provisioning the individual nodes with keys for all future trusted clients. The basic approach is to establish shared keys between resource servers and a trust anchor. When a client wants to establish a trust relationship with a resource server it requests a key from a trust anchor. The trust anchor asserts a secret key or a public key of the client that can be conveyed to the resource server.