The order we intend to build in, and an honest list of what is not coming. If something here is a gate for you, tell us — at this stage the order is set by what customers actually need.
There are no dates on this page, deliberately. We would rather tell you the order and be right than tell you a quarter and miss it. If you need a date for a procurement process, ask us and we will give you one for the specific thing you need — with the reasoning behind it.
Everything below is built, tested and running. It is worth reading before the roadmap, because the roadmap is short by comparison and that is the point.
Single sign-on comes first because it is the thing most often required before anybody gets as far as evaluating a control.
Google Workspace, Microsoft Entra ID and Okta, over OpenID Connect. You register the app in your own directory and keep your own credentials.
Where you use an identity provider, we verify the factor it asserted rather than asking your people for a second one they already provided. Authenticator-app codes for accounts with no directory behind them.
Proving control of your email domain before it routes anybody to your identity provider, so no other tenant can claim it.
Review campaigns where a revocation actually removes the access, rather than producing a list somebody has to action separately. Covers what SOX and SOC 2 both ask for.
A conflict matrix you define, checked when access is granted rather than discovered at audit — with a recorded override for the emergencies where somebody genuinely must do both.
One workflow can satisfy SOX, SOC 2 and ISO 27001 at once. Reports will let you pick the framework your auditor is asking about.
Making the record append-only at the database level, not by convention — so “could this have been edited” has a better answer than “we do not do that”.
SCIM, so removing somebody from your directory ends their session here immediately rather than when it expires.
Rules you configure, delivered through the notifications you already receive.
Proving it is still you at the moment you approve a change, not merely that you signed in this morning.
The ISO 27001 and SOC 2 incident workflow, including a recorded decision about whether anybody had to be notified.
Onboarding assessment and periodic review, with suppliers linked to the systems that depend on them.
Vulnerability remediation, and access review and recertification, in the same shape as clause 10.2.
Listed because finding this out during a procurement review is worse for both of us than reading it here. If one of these is what you need, say so — it is a conversation, not a closed door.
Not planned, and it is not a small addition. It would need protected health information handling, a breach-notification workflow, and a considered answer about ticket content reaching a model provider. We would want to plan it properly rather than claim it.
Available self-hosted only, and deliberately. If we hold your SOX-relevant controls, this platform sits inside your audit scope and your auditor needs assurance over us. Self-hosted keeps the controls yours.
Raising tickets by sending an email is not supported. Requests come in through the portal or the API.
Neither is built. Deferred while the control and evidence work is the thing that differentiates the product.
At this stage the order is set by what customers actually need, not by a committee. A requirement that blocks a deal is the strongest possible argument for moving something up, and we would rather hear it now than read it in a procurement questionnaire.
This page is maintained by hand. The internal roadmap it reflects lives in the Trenchant Countersign repository; change that first, then this page.
Trenchant Countersign supports controls. It does not make anybody compliant, certified or conformant.