Why MitID signing is off by default

Most features Welkent ships are available to every account the moment they're released. MitID signing isn't one of them. It's off by default, and turning it on for a given account is a deliberate action taken by Welkent's own support team, not a setting a customer can flip themselves.

A feature with real cost attached to every use

MitID signing isn't free to offer. Every signed document that goes through MitID carries a broker fee, real money spent per signature rather than a flat platform cost. Combine that with the fact that not every account needs legally binding e-signatures for every quote, and turning MitID on by default for every account would mean absorbing a cost that only makes sense for the subset of customers who actually want it.

Gating it behind a support-enabled flag means the feature only gets turned on for accounts that specifically want it, rather than every account silently carrying its cost structure whether they use it or not. It also means support has a natural moment to make sure an account actually understands what they're turning on, rather than a self-serve toggle someone flips without realizing there's a per-signature cost attached.

Enforced twice, not once

The gate itself is a database row: whether a given account has MitID enabled. What matters is that this gets checked in two separate places, not one.

On the frontend, an account without the flag simply doesn't see MitID as a sending option; the UI doesn't offer something the account can't use. But hiding a UI option is a convenience, not a security boundary, since a UI is just a suggestion about what a client is allowed to request. The actual enforcement happens on the backend: any attempt to send via MitID gets checked against the same flag, and an account without it enabled gets a 403 regardless of what the frontend showed or didn't show.

That second check is the one that actually matters. A UI-only gate can be bypassed by anyone who can call the API directly, whether that's a browser extension, a direct request, or a client the account rolled themselves. Checking at the API boundary means the gate holds regardless of how the request arrives, not just for the one client Welkent controls.

A pattern worth repeating

Gating an expensive or sensitive capability behind an explicit flag, checked both in the interface and at the API boundary, isn't specific to MitID. It's the shape any feature with a real per-use cost or a compliance implication probably needs: don't rely on the frontend to be the only thing standing between a request and an expensive action, and don't roll a costly feature out to every account by default just because it's technically available to everyone. Cost and risk should be opt-in, not ambient.

More on how signing fits into the rest of the platform is on Welkent's product page.