Have questions?

That's great - we've got answers

Frequently Asked Questions

General product questions

What is a user access security broker?
User access security broker is a security layer that is designed to deal with user-oriented security of any web application without any change in the application code.

The main benefits of introducing a user access security broker are:
  • increasing the level of security of the authentication process
  • adding customizable authorization steps wherever it’s necessary
  • making it possible to create unified security policies for the entire organization easily

Secfense is an example of a user access security broker.
Why should I care about unified security policies?
Because managing a variety of security policies, different for each application, makes it hard or even impossible to manage and control.
What problem Secfense solves?
Secfense fights with complexity and inefficiency. In large organizations, there are still hundreds of applications that authenticate users only against their passwords and this may often cause a lot of security problems. It wasn’t possible before to protect them all with 2FA due to the huge costs of software development and further maintenance. 2FA was introduced to 1 app and there’s still 99 that could cause a potential security breach. Secfense changes that.

We protect against phishing aimed at stealing user credentials and other account takeover techniques by introducing 2FA on any application. In just minutes. So organizations no longer need to stress about picking only a few sensitive apps to protect with 2FA and hoping that the breach will not come through some other app. It’s possible now to can introduce any 2FA method to all the apps and protect the whole organization with a battle-tested security solution.
How is Secfense built?
Or the other way to ask this question. What is the architecture?

Secfense in big simplification is a form of a security layer. It works as a reverse proxy that sits between any internal application and the external user.

Secfense is also an enterprise service bus (ESB) for security modules such as two-factor authentication (2FA). Each 2FA method is completely independent from the protected applications. This means that it can be exchanged instantly without affecting the application workflow.
Can Secfense replace VPN within an organization?
It’s safe to say that VPN (especially protected with password only) is not very secure. Traditional network perimeter has evolved and according to the Zero Trust Model we need to abandon the "idea of a trusted network". Instead, it’s better to rely on a strongly authenticated user (with 2FA). This is where Secfense can help. It can be either applied to SSL-VPN as an extra layer of security or become a replacement - security broker that will keep the bad guys off and let only the legitimate users in.
How and where do you keep passwords?
We don’t. In order to operate Secfense doesn’t need to process and store users passwords. We leave the application authentication intact and act on top of it.
How is it possible that Secfense can be deployed in minutes not months?
We shift the paradigm of implementation of 2FA. With Secfense 2FA is no longer the domain of software, but rather the network. Instead of tying each app individually to the selected 2FA method - which is time and money consuming and requires development efforts, you just reroute the web traffic throughout our proxy - which is as simple as changing DNS entry or a firewall rule.
What 2FA methods are supported by Secfense?
Secfense is a method agnostic enabler. Which means it can be used to deploy ANY method available. Currently, we support FIDO U2F - the most secure method available and TOTP (compatible with Google Authenticator). If needed, other methods, such as legacy tokens, voice and face biometric authentication can be enabled on the platform.
Is Secfense available on-premises? Or is SaaS?
Due to the sensitive nature of the data flowing through Secfense most of our customers prefer on-prem deployments, either as a physical or virtual appliance. In the near future, we plan to extend the offering to SaaS.
Which 2FA method should I use after introducing Secfense?
U2F security keys are one of the most secure and efficient ways to use 2FA. They’ve been battle-tested by the giants, such as Google, Facebook, Twitter and are currently the only 2FA method that can resist phishing. They work out-of-the-box for most environments, are easy to use and manage and are affordable.
They’re based on public key cryptography but without the problematic infrastructure of legacy PKI systems.
Why should I use Secfense if I already I already have 2FA in my organization?
If you already use 2FA to protect your most sensitive applications, you can still use Secfense in one of two scenarios:
  • seamlessly extend existing methods to other apps
  • seamlessly replace legacy with state-of-the-art methods for the selected app or user base
How does Secfense know how to protect the application without knowing its code?
During the phase called “self-learning” Secfense probes the target application to gain knowledge on how it’s built. After performing the pattern analysis on both backend and the frontend, Secfense issues custom-tailored protection for the selected application.
Is Secfense available on-premises? Or is SaaS?
Due to the sensitive nature of the data flowing through Secfense most of our customers prefer on-prem deployments, either as a physical or virtual appliance. In the near future, we plan to extend the offering to SaaS.
Which U2F keys are supported?
Secfense supports all U2F compatible keys. It’s up to you to choose the vendor.
Can Secfense manage my SSL certificates?
Yes. Secfense can either use your existing SSL certificates or generate new ones for you. It can also hide behind your SSL-terminating device and make consume unencrypted traffic.
What protocols does Secfense support?
How does Secfense scale within an organization?
You can start with a single cluster for high-availability and add more nodes if necessary. Additional nodes can be span between your own datacenter, private and public cloud.
Does Secfense provide high-availability?
Yes. High availability is provided by the redundant nodes of a cluster.

Demo and PoC

How can I test-drive Secfense in my organization?
You’ll be given a demo version of our virtual appliance to run within your testing environment. After selecting an application for testing, you should somehow redirect traffic between your testing users and the application (most of the time by changing DNS entries or firewall rules). Best way to start is by filling out the form with a pre-implementation user survey here
Can I see live-demo on my app remotely?
Yes. If your application can be accessed from the public internet, we can “wrap” it with Secfense to demonstrate all functionalities without any changes necessary. Here is a demo that was performed in public on Amazon.com. If you like to have such demo done on your app you can schedule a call with us and point out a site to do a demo on.
Can I use Secfense to protect my SSH-enabled hosts?
Yes. With Secfense SSH gateway we can carry out the “good” man-in-the-middle attack on your infrastructure in order to apply additional security measures (such as multi-factor authentication) on your users’ SSH sessions.
Does Secfense use man in the middle act to prompt for a second factor?
This questions comes up in various forms. And for a good reason. During our live demo where we show 2FA being deployed on Amazon.com we locally changed Amazon DNS entry and run it through our network. During the demo this obviously has a right to work only on our laptop since we do not control Amazon network. The purpose of the demo is to show that we can deploy 2FA without touching application code. When Secfense is deployed on the real environment it lays near a load balancer or WAF.

To make it even simpler - as long as our client controls DNS entries of the target apps it is possible to deploy Secfense there. You can think of us as a Cloudflare for 2FA.
Can you protect Office365, Salesforce, etc.?
At this stage we’re focused on applications owned by the company, so currently we don’t support SaaS products. But we’re working on expanding Secfense operations to SaaS environment, though.
What does it mean, that Secfense is 2FA enabler and not provider?
Being a multi-factor authentication method enabler means that we activate any 2FA method to any web application. We are not a producer of 2FA methods, but we integrate them on our platform making it available for every web application that Secfense sees on the web. That means that if you are currently using some specific 2FA method in your organization, attaching it to the Secfense integration bus will make it the next method to choose and deliver to the application on the fly, at the network layer.
Is 2FA for web services only or for mobile apps as well?
Secfense was designed for web-based applications as it leverages the standards both on the protocol level as well as on the client side (browser). It might be deployed for some mobile environments, but that requires some extra support.
How does Secfense integration look like?
Or, how is Secfense deployed?

Secfense is delivered to the customer in the form of a physical or virtual appliance.

It is placed on the route between users and applications in such a way that it can analyze and modify HTTP(s) traffic - usually near load-balancer or application firewall. Depending on the client's preferences, Secfense can work as TLS termination proxy or work on already decrypted traffic.

Due to the confidentiality of communications Secfense never communicates with external hosts, nor does it "call home" for reporting purposes.

Secfense installation options:

Inline (Secfense as SSL/TLS proxy)

Inline (Secfense working on decrypted traffic)

On-a-stick (flow on the load-balancer is "wrapped" by Secfense)

What is ‘the learning stage’ in Secfense?
Or, how exactly does the traffic inspection and application learning stage looks like?

In the learning process stage, Secfense launches a probe into the target application to scan it for requests (and responses) related to user authentication. It is at this stage that both the network traffic patterns and the user interface patterns are collected.

In most cases, the learning process is automatic and takes just several seconds. In rare cases, where patterns are not recognized automatically, the administrator performs manual tuning.

After applying the previously learned pattern, the application becomes instantly protected by the selected 2FA method. During the next login, application users will be prompted to activate the 2FA component.

This is possible by intercepting requests at the user interface level and blocking unauthorized traffic in the HTTP(s) layer.

The user remains in the domain of the protected application (no redirection to an external service), and the 2FA registration/use process seems to be an integral part of the protected application.

This mechanism works for both traditional applications (where the HTML code is rendered completely on the server side), as well as the so-called SPA (Single-Page Apps).

Here's a link to our 7-minute showcase that we did on the Finovate Europe conference in London February 2019. It shows exactly how 2FA deployment looks like. We show the demo on Amazon.com but in fact, it can be done on any other web-based application (so you can send us your web app too and we will show a demo on that).

At this presentation, we show U2F as a 2FA method, it might as well be Google Auth. or a biometric method.
Does Secfense collect data about the user before the first login?
The learning stage is a one-time process designed to teach Secfense the characteristics of the web application, which will be protected by 2FA methods.

The entire Secfense integration with applications closes in a few steps: Step 1: create a virtual host for the application in Secfense (DNS name and current application IP are defined)
Step 2: network traffic to the application is directed by rev-proxy Secfense (this action is outside Secfense, performed by the network administrators) - now Secfense sees the traffic but still does nothing with it, behaves completely passively.
Step 3: Learning process - an attempt to log into the application with the special username - understood only by Secfense and providing Secfense the knowledge of the target application.. It's the end of integration. In Secfense a pattern is created for a given application that just needs to be applied and from now on 2FA users will be required. 2FA methods in Secfense can be assigned per application to all or selected users.

Here's a link to our 7-minute showcase that we did on the Finovate Europe conference in London February 2019. It shows exactly how 2FA deployment looks like. We show the demo on Amazon.com but in fact, it can be done on any other web-based application (so you can send us your web app too and we will show a demo on that).

At this presentation, we show U2F as a 2FA method, it might as well be Google Auth. or a biometric method.
Will Secfense failure make the use of the target application impossible?
No. In the unlikely event of a failure, it can be easily disabled without disruption of a target application.


What are microauthorizations?
One of the crucial functionalities of Secfense are microauthorizations. This functionality makes it possible to stop the user when he or she reaches for some specific resources or wants to perform some specific actions in the protected application. In such a case, Secfense takes over communication and triggers one of two scenarios:
  • In the OWNER scenario, Secfense asks the user to re-authenticate
  • In the SUPERVISOR scenario, Secfense asks the third party for authorization

Since Secfense, as described above, works as an intermediate security layer, so microauthorizations can be added inside of the application anywhere, and it only takes minutes to deploy.

Microauthorizations (in the OWNER scenario) introduce an increased level of granulation under the Principle of Least Privilege. This means additional protection against attack on a stolen active session or other attacks against an already logged-in user (including real-time phishing or malware).

Microauthorizations (in the SUPERVISOR scenario) leave authorization of particularly sensitive resources requests in the hands of selected and trusted users.

Regardless of the scenario, the additional effect of microauthorizations is the protection of sensitive resources against risks such as:
  • automatic export (with or without the consent of the user)
  • uncontrolled leakage of confidential data through the application interface


That is why the best tool to include in microauthorizations are U2F / FIDO2 cryptographic keys or local authenticators compliant with the WebAuthn standard. The 2FA methods based on one-time codes (SMS, TOTP) will not work because of too much of user involvement in the process.

In the case of the OWNER scenario, the access to the protected resource requires the user to simply touch the cryptographic key that was used during the authentication.

In the case of SUPERVISOR scenario, access to the protected resource requires the same action as above but needs to be performed by the privileged user with a privileged cryptographic key.