The mechanics of getting into Ettex and what that means for access: Google sign-in where it is enabled, one-time email codes, passkeys, and what is not supported yet.
Authentication is the part of security people actually touch, so it is worth describing precisely rather than in adjectives. Ettex supports three ways in, and which ones you see depends on what is enabled for your instance.
SAML and SCIM provisioning are not supported. If your organisation requires either — and for many security teams SCIM is the blocker rather than SAML, because deprovisioning is what they actually care about — tell us, because that is what drives the order we build things in. We would rather say so plainly here than have you discover it during a trial.
Passkeys can only be registered from an active session, which is deliberate: it means a stolen email inbox is not enough to add a new credential. The practical consequence is that you register one while you are already signed in, not during a recovery.
Ettex is local-first: the authoritative copy of a document lives on your device rather than on a server, and syncing is added on top. That shapes the security picture more than any single setting — it means the product keeps working without the network, and it means the copy you hold does not disappear if a service does. The trade-offs that come with it are covered in the piece on why we build this way, including the ones that are inconvenient for us to mention.
Yes — all three supported methods are passwordless: Google sign-in, a one-time email code, or a passkey.
Not yet, and neither is SCIM provisioning. If your organisation requires them, telling us affects prioritisation.
So that access to your inbox alone is not enough to register a new credential. It is a deliberate restriction rather than an oversight.
SSO removes a password per service and concentrates risk in one place. That trade is usually worth making — provided the identity provider itself is protected better than the accounts behind it.
Turning on two-factor authentication is the single highest-value security change most small teams can make. Which second factor you pick decides whether it stops the attack that actually happens.
Forced ninety-day changes, three special characters, no repeats — most password rules were written from intuition and make passwords weaker. The current guidance says something close to the opposite.