In the arms race to secure environments, codifying permissions often becomes an afterthought in the wake of setting up a new access tool. I often speak with organizations that either don’t know who has permission to what, or have no permission definitions at all. I once onboarded an enterprise level digital communications company that was losing productivity trying to keep track of who had access to their Kubernetes resources.

Telehealth and remote patient monitoring solutions enable healthcare providers to deliver care beyond traditional clinical settings. However, developing and deploying these digital healthcare solutions involves navigating complex challenges, particularly regarding data privacy and regulatory compliance. Ensuring adherence to HIPAA regulations while securely managing remote infrastructure adds layers of complexity for healthcare IT, security, and engineering teams.

At Teleport we solve a wide range of problems: letting our customers access their infrastructure remotely without passwords or shared secrets, replacing shared credentials in CI/CD workloads with mTLS, and eliminating the need for VPNs to enable Just-In-Time Access to web apps, cloud consoles, databases, and more. Device trust was the last missing piece in replacing VPNs, as they offer a powerful feature letting customers pin access to specific networks.

With the rise of infrastructure complexity, organizations must improve their strategies to quickly investigate and mitigate unauthorized system access and internal identity threats. Teleport has already highlighted the importance of identity threat detection and response and introduced features to support security incident containment. This article builds on these ideas by presenting additional metrics to detect suspicious employee behavior and options for expanding detection capabilities.

FedRAMP authorization can take years. The process is time-consuming, expensive and risky, requiring extensive human capital and dedicated technical resources from the initial project standup through continuous monitoring and compliance reporting before an Authorization To Operate (ATO) has been achieved. The Teleport Access Platform significantly reduces the time, cost and risk associated with FedRAMP compliance by addressing many of the most difficult FedRAMP control requirements.

It’s that time again — for a brand new major release. Our team releases major versions of Teleport every 4 months. Here we introduce Teleport 16. This post goes into detail about Teleport 16 breaking changes, bug fixes and improvements. In Teleport 16, we focused on new features and enhancements to enable our customers to implement mitigations to protect against an IdP Compromise.

Our customers use Teleport to solve a wide range of problems: They access their infrastructure remotely without passwords or shared secrets, and replace shared credentials in CI/CD systems and workloads with mTLS. They eliminate the need for VPNs and enable Just-In-Time Access to web apps, cloud consoles, databases, and more.

With Teleport 15.2, we’ve added a preview for Teleport Workload Identity. Teleport Workload Identity lets teams bootstrap and issue identities to services across heterogeneous environments and organizational boundaries. A core value of Teleport comes from having a central access platform, and we believe that humans and machine access need to join and access using the same zero-trust best practices.

We open sourced Teleport in 2015 with a mission to secure access to infrastructure. It has since become a popular open source project with over 15,000 GitHub stars and is licensed under AGPLv3. We have been offering the stable releases of the Teleport Community Edition binaries and images distributed under the permissive Apache 2.0 license.

Teleport is an open source company. We develop in the open, including full disclosure of security issues in our changelogs and pull requests. We share our penetration tests and key compliance reports. Despite this, our communication to open source users and integration with automated security tooling needed improvement. We needed a standardized way to refer to our vulnerabilities so that when two people (or systems) talk about a vulnerability, they know they’re talking about the same thing.