Security shouldn’t require blind trust.

• Standards over invention. Authentication is built on FIDO2 and WebAuthn, not a proprietary protocol.
• No shared secrets to steal. The design removes passwords and long-lived SSH keys rather than storing them more carefully.
• Explainable decisions. Every access decision should be traceable to the signals it used and the policy rule that applied.
• Least data necessary. Bastyx should never need biometric data, private keys or passwords, so it’s designed never to receive them.
• Say what’s true. We describe shipped capabilities as shipped and planned ones as planned. We list certifications only after they’re complete.

Bastyx sits between people and the resources they access. Authenticators prove who someone is; Bastyx decides whether that person, on that device, may reach that resource right now, and records the outcome.

The planned components are:

• Directory. People, teams and roles, either managed in Bastyx or synchronized from your identity provider.
• Device enrollment. Laptops and workstations are enrolled and bound to a person, so policy can require a known device.
• Authenticator registry. Public keys and credential identifiers for each person’s passkeys and security keys. Private keys stay on the authenticator.
• Policy engine. Evaluates explicit rules against identity, device, authenticator, resource and risk signals. Returns allow, step up, require approval or deny.
• Access integrations. Workstation login (Windows, Linux), SSH and application sign-in, each asking the policy engine before granting access.
• Audit log. An append-only record of authentication events and administrative changes.

Bastyx uses FIDO2: the W3C WebAuthn API together with the FIDO Alliance’s CTAP2 protocol for external authenticators. These are the standards behind passkeys and modern security keys.

How a FIDO2 sign-in works

1. At registration, the authenticator generates a key pair for Bastyx. The public key is stored by Bastyx; the private key never leaves the authenticator.
2. At sign-in, Bastyx sends a fresh random challenge.
3. The authenticator verifies the person locally (a touch, a PIN, or a fingerprint matched on the device) and signs the challenge together with the origin it was requested from.
4. Bastyx verifies the signature with the stored public key.

Because the signature is bound to the origin, a credential registered for Bastyx can’t be replayed on a look-alike phishing domain. Because nothing secret is stored server-side, there’s no password database to leak.

Planned controls on top of FIDO2

• Policies can require a specific authenticator type, such as a hardware security key, for sensitive resources.
• Step-up verification when risk is elevated or a resource demands it.
• Short, policy-defined session lifetimes for infrastructure access.
• Recovery that requires admin approval and a second registered authenticator, so a lost key can never be used to recover itself.

What Bastyx is designed to process:

• Identity attributes: name, work email, team and role.
• Device identifiers and the signals policies use, such as enrollment state.
• Public keys and credential identifiers for registered authenticators.
• Authentication and administrative events, including time, resource, device, result and network information such as IP address.

What Bastyx is designed never to receive:

• Passwords. There aren’t any in the flows Bastyx manages.
• Biometric data. Fingerprint and face matching happen on the device or security key.
• Private keys from passkeys or security keys.

• Bastyx Cloud. Hosted and operated by us.
• Customer-hosted. The control plane runs in your environment for teams whose policy or regulation requires it.

If you believe you’ve found a security vulnerability in Bastyx or this website, please email security@bastyx.com. Our machine-readable contact details are in security.txt.

Please include

• A description of the issue and its potential impact.
• Steps to reproduce, or a proof of concept.
• Affected URLs, components or versions.
• How you’d like to be credited, if at all.

While testing, please

• Only access data that belongs to you, and stop if you encounter anyone else’s.
• Avoid degrading service for others. No denial-of-service or volumetric testing.
• Don’t use social engineering or physical attacks against our people or premises.
• Give us reasonable time to fix an issue before disclosing it publicly.

What we’ll do

• Acknowledge your report and keep you informed as we investigate.
• Tell you when the issue is fixed.
• Credit you publicly if you want to be credited.

No certifications or third-party audit reports are listed on this page yet. When an audit is complete, we’ll list the report type, the auditor, the period covered and how to request a copy. We won’t present work in progress as complete.

If your team needs specific evidence for a security review, tell us what you need and we’ll answer directly.

Security reports and questions: security@bastyx.com