Security requirements are usually relatively easy to manage when using local restrictions in conventional closed systems. They become more complex in the distributed system landscape of an SOA. Not limited to only an application or an application domain anymore, security must work across a range of applications and business processes. Numerous security standards have been created in order to realize these comprehensive security requirements. These include WS-SecurityPolicy, WS-Trust, XML Encryption, XKMS, XML Signature, WSFederation, WS-SecureConversation, SAML1, SAML2, and many more. Currently, no product or open source framework can fully support all of these standards. In our experience, incompatibilities arise whenever an SOA product or deployed Web service framework needs to communicate outside of its small ecosystem. Not surprisingly, project managers who are confronted with increasing expenses tend to start looking for viable alternatives. They then usually choose to develop inflexible solutions in-house that can quickly implement risky anti-patterns, such as transferring usernames and passwords within the functional payload. The variety of different standards makes it difficult to formulate a clear understanding of the available security standards and internal product dependencies, in light of the individual restrictions to designing a well-secured system. Our aim is to provide IT experts and SOA architects with tips on how to handle security responsibly, using tried and true best practices as a basis.