Biometrics and behavioral authentication have become a prominent part of modern access protection because they reduce password dependence, increase in-entry convenience, and reduce some of the phishing risks. At the same time, such mechanisms affect not only security, but also confidentiality, data quality, legal restrictions and user confidence.
Terms and Classification
Implementation architecture
Threats and vulnerabilities
Law and regulation
Ethical risks
Protection practices
Life cycle of data
Road map of implementation
Choice of technology
Terms and Classification
Biometrics is the recognition of a person on physiological grounds, such as a fingerprint, a face, an iris of the eye or a voice; in the applied sense, this often includes patterns that the system stores instead of the original image or audio. It is important to distinguish between the original biometric image and the biometric pattern: the template is a transformed representation of the features, suitable for comparison, but still sensitive in terms of the risk of leakage.
Behavioral authentication uses behavior patterns: the speed and rhythm of typing, mouse movement, navigation features, the nature of the device interaction, and even the context of use. Unlike “one-time entry”, such systems often work continuously and assess how much behavior at the current moment is similar to the profile of a legitimate user.
It is important to distinguish between authentication and identification. Authentication confirms that the user is indeed the one for whom he issues himself, and identification establishes his identity according to known system characteristics. This difference affects both the decision architecture and the legal data processing regime.
Implementation architecture
In practice, biometrics and behavioral authentication should not be designed as “one entry mechanism” but as part of the overall access management model. The logic of implementation is usually built around three solutions: where the data is located, how exactly the decision on admission is made and what happens when the main channel is made or is not available. This is where it is determined whether the system will be a convenient security enhancement or a source of new risks.
The first architectural option is local processing on the device. In this scenario, the template is stored in a secure user environment, for example in the hardware security module, and only the verification result or cryptographic confirmation is transmitted to the server. This approach reduces the area of the attack, because the organization does not accumulate a centralized base of sensitive patterns, and therefore reduces the price of possible compromise.
The second option is centralized processing on the side of the organization or vendor. It is convenient for policy management, auditing, and integration with IAM, but requires much more stringent measures to protect storage, transfer, logging and power-sharing channels. For biometrics, this is especially critical, because the pattern, even in a transformed form, remains a sensitive object, and for behavioral authentication, the value is not only the final solution, but also the array of raw telemetric traits.
The third option is hybrid architecture. In it, biometrics is used as one of the factors, but not as the only source of trust. In practice, this means a bundle of “biometry + cryptographic factor + contextual risk scoring” where the system takes into account the device, geography, time, type of operation, and the user’s behavioral profile. This approach is better suited to the principle of the least sufficient trust and allows you not to block the user with a single error of the sensor or drift of the model.
Separately, it is necessary to design the boundaries of trust. If biometrics is used on a mobile device, you should determine where the trust in the OS and the hardware module ends, and where the control from the application begins. If a server check is used, it is necessary to separate the collection, storage, matching and decision-making contours so that the compromise of one segment does not open access to the entire system.
For behavioral authentication, the presence of an adaptive model is critical. The user's behavior changes due to a new device, remote work, an injury to the hand, a change of habits or just a new scenario of using the system. Therefore, the model should not only issue scoring, but also be able to work with sensitivity thresholds, retraining windows and manual validation of disputed cases. Otherwise, the system will either begin to massively mistakenly reject legitimate users, or lose meaning as a protection mechanism.
Finally, in architecture it is necessary to determine the folback mechanisms in advance. Biometrics should not be the only way to access. The standby path should include an alternative factor, a recovery procedure, and an understandable model of escalation for the support service. This is important not only for convenience, but also for security: if the failure of the main channel cannot be safely processed, users will begin to bypass protection or create unauthorized exceptions.
Threats and vulnerabilities
One of the main threats to biometrics is attacks, that is, attacks in which an attacker tries to deceive the sensor during the presentation of a biometric feature. This includes fake prints, masks, photos, screens with image playback and other ways to deceive the sensor; it is for such cases that ISO/IEC 30107 describes the approaches to presentation attack detection, or PAD, that is, the automatic detection of counterfeiting when the feature is captured.
Behavioral authentication has different risks. First, distorted data can fall into the profile, which makes the model worse distinguish between normal and suspicious behavior. Secondly, it is possible to simulate behavior when the attacker tries to reproduce the characteristics of the user. Thirdly, over time, the quality of the models decreases: the user's habits change, and without regular adjustment, the number of false failures and false tolerances increases.
The risks of template leakage should be taken into account separately. Even if the system does not store the original image of the face or fingerprint, the template itself may be sensitive: with insufficient protection, information recovery, the comparison of profiles between systems and the reuse of data in circumvention of the original purpose of processing are possible. Therefore, architecture should be evaluated not only by the accuracy of recognition, but also by the ability to protect the biometric or behavioral footprint itself.
Law and regulation
In the Russian model of regulation, biometrics is considered as a special area of personal data, and if it is used to establish identity, it falls under the regime of biometric personal data under Article 11 152-FZ. The practical conclusion is that it is not enough for an organization to simply “collect a photo or a voice”: it is important whether this information is used to identify or authenticate a person.
As a general rule, the processing of biometric personal data is allowed only with the written consent of the subject, and in a number of cases expressly listed by law - without it, for example, in connection with justice, execution of judicial acts, compulsory fingerprinting or other grounds provided by law. For business, this means that standard ACMS scenarios (access control system), login to an application or confirmation of an operation usually require a written consent form, and not just a checkmark in the interface.
Since June 1, 2023, the Russian Federation has a special regime for identification and authentication using biometrics within the framework of Law No. 572-FZ, as well as by-laws on accreditation and the procedure for processing biometric data. For practice, this is important for two reasons: firstly, a circle of permissible participants and procedures is defined, secondly, some of the biometric scenarios are now tied to the Unified Biometric System and commercial biometric systems operating in accordance with the established procedure.
This is followed by a key limitation: not all biometrics processing in a commercial system is permissible in an arbitrary form. If an organization builds a service on a person’s photo or voice for identification or authentication, it must check whether the scenario falls within the requirements of Law 572‐FZ, whether access is needed through the EBS (Unified Biometric System), whether accreditation is required, and whether the processing does not apply to the exceptions provided by law. For architecture, this means that legal scrutiny must proceed before technical implementation, not after.
Separately, it should be taken into account that the provision of biometrics should not become mandatory unless the law explicitly requires otherwise. The explanations for 152-FZ note that the refusal of a citizen to provide biometrics or consent to its processing should not automatically entail a refusal of the service, if there is no special legitimate obligation to use biometric data for such service. For the product team, this means the need for an alternative entry scenario and equivalent access to the service.
The written consent regime is also important. In 2025, the law on personal data was amended, according to which consent to the processing of personal data should be obtained separately from other documents and information; this strengthens the requirement for separate consent and reduces the risk of “hidden” consent in user documents. For biometrics, this is especially significant, because consent must not only be separate, but also in shape to correspond to the level of data sensitivity.
For employers and ACS scenarios, this means even more rigorous verification. If the photo of the employee is used to control access, Roskomnadzor considers such information as biometric personal data, and written consent is required under the rules of Article 9 and Article 11 152-FZ. In other words, the photo on the skip itself can be ordinary personal data, but as soon as it begins to be used for automatic identification, a special mode is switched on.
Finally, the design should take into account the requirements for the notification of Roskomnadzor, the purposes of processing, localization of data and the security of personal data processing in general. Even if a specific biometric scenario is legal, the organization is still obliged to define the purposes, categories of data, retention periods, the composition of protection measures, the powers of employees and the conditions for termination of processing. Therefore, the documentation should not only have policy and consent, but also clearly fixed the purpose of processing, legal basis, technical implementation, retention period and data removal procedure.
Ethical risks
The ethical problem of biometrics is not only the technology itself, but also in the context of its application. If the user cannot refuse biometrics without losing access to a meaningful service, formal consent ceases to be completely free and becomes disputed in terms of trust and integrity. Therefore, it becomes mandatory to have an understandable alternative: PIN, hardware key, backup code or other way to confirm identity.
Another important risk is the shift in recognition between user groups. For facial, voice, or behavioral pattern recognition systems, this means possible errors in people of different ages, gender, health status, or features of the device. Such mistakes quickly turn from a technical problem into an ethical one if they result in unjustified refusals, blockages or discrimination.
Finally, continuous behavioral authentication can be perceived as constant observation. Even if the system is needed to protect against session capture or insider activity, the user may perceive it as too deep an analysis of their digital activity without sufficient transparency. For this reason, transparent notification and explanation of the logic of processing become not a supplement, but part of the security system itself.
Protection practices
The most reliable approach involves protecting templates and minimizing data. Protective mechanisms for biometrics should prevent direct storage of the original image and reduce the risk of recovery or comparison between systems. For behavioral data, this is achieved through aggregation, pseudonymization and limitation of trait detail.
To protect against presentation attacks, you need to introduce PAD mechanisms and check them according to formal criteria, not according to the supplier's statements. ISO/IEC 30107-3 sets the basic principles of testing and reporting for such mechanisms, that is, a description of the test scenario, the results metrics, the thresholds of acceptance and the format of the presentation of the results. This is convenient to use as a basis for the requirements for the vendor and internal acceptance of the solution.
For behavioral authentication, model protection, control of changes in user behavior and data validation are important. It is useful to save not only the final scoring, but also the version of the model, the thresholds, the reason for the decision and the history of the changes, so that you can explain why access was allowed or blocked.
Metrics and Quality
It is necessary to assess such systems not only by convenience, but also by clear safety metrics. For biometrics, FARs are traditionally used – a share of false tolerances, FRR – a fraction of false failures and an EER – the point of equal error when FAR and FRR approximately coincide. These indicators help to see a real compromise between security and convenience, rather than relying on subjective impressions.
At the same time, low FAR does not always mean a good solution. If the system is too rigid, the FRR grows, users start to bypass the protection, and the support service receives a stream of calls. Therefore, metrics need to be associated with business processes: entry time, the number of calls for access recovery, the number of blockages and the percentage of successful repeated attempts.
For behavioral authentication, it is useful to measure the stability of the profile over time. If the model is “outdated” too quickly, the system will either mistakenly reject legitimate users or loosen controls to an ineffective level. That is why piloting is better carried out not in the laboratory, but on a real user flow with control of thresholds and logging of errors.
Life cycle of data
The most underrated aspect is the life cycle of biometric and behavioral data. At the collection stage, the objectives, list of features, shelf life and disposal procedure should be defined. At the stage of operation, access control is needed,
encryption, logging, and regular verification that data is not used beyond the stated purpose.
For the user, it is necessary to provide a clear mechanism for revocation of consent, removal of the template and transition to an alternative method of entry. In systems where biometrics is stored locally, it is usually easier; in centralized platforms, it is more important to eliminate dependence on a single provider and determine in advance how migration or data removal is performed. For behavioral authentication, another task is added: the removal of the history of behavior should be technically and organizationally enforceable, not just declared.
Logs also require caution. If the original biometric images, raw behavioral events or detailed features remain in the journal, the system creates a secondary array of sensitive data. Therefore, in the logs it is better to store event identifiers, the model version, the result of verification and the technical context, rather than the complete biometric routes.
Road map of implementation
Step-by-step implementation is not to start with the choice of a vendor, but with the classification of the scenario: what exactly is protected, what type of data is used, where the processing will take place and whether the organization has a legitimate basis for such a regime. Then the risk assessment, the choice of architecture, legal verification and only after that – piloting. Such an order is necessary to avoid a situation where a technically correct solution is unsuitable due to regulatory restrictions.
At the stage of preparation, it is useful to fix the initial conditions: the type of biometrics or behavioral data, the role of the mechanism in authentication, the availability of an alternative entry method, the format of consent, storage requirements and the boundaries of the responsibility of the vendor and the operator. This will be the basis for the subsequent implementation table: it will be convenient to break the stage, purpose, input artifacts, responsible, control points and completion criteria.
Further, logic is usually built as follows: first, a legal and architectural model is formed, then a pilot is carried out on a limited group, after which accuracy metrics, failure rate, support load and resistance to errors and attacks are checked. Already as a result of the pilot, you can proceed to scaling, but only if there are approved procedures for restoring access, logging, responding to incidents and deleting data.
Terms and Classification
Implementation architecture
Threats and vulnerabilities
Law and regulation
Ethical risks
Protection practices
Life cycle of data
Road map of implementation
Choice of technology
Terms and Classification
Biometrics is the recognition of a person on physiological grounds, such as a fingerprint, a face, an iris of the eye or a voice; in the applied sense, this often includes patterns that the system stores instead of the original image or audio. It is important to distinguish between the original biometric image and the biometric pattern: the template is a transformed representation of the features, suitable for comparison, but still sensitive in terms of the risk of leakage.
Behavioral authentication uses behavior patterns: the speed and rhythm of typing, mouse movement, navigation features, the nature of the device interaction, and even the context of use. Unlike “one-time entry”, such systems often work continuously and assess how much behavior at the current moment is similar to the profile of a legitimate user.
It is important to distinguish between authentication and identification. Authentication confirms that the user is indeed the one for whom he issues himself, and identification establishes his identity according to known system characteristics. This difference affects both the decision architecture and the legal data processing regime.
Implementation architecture
In practice, biometrics and behavioral authentication should not be designed as “one entry mechanism” but as part of the overall access management model. The logic of implementation is usually built around three solutions: where the data is located, how exactly the decision on admission is made and what happens when the main channel is made or is not available. This is where it is determined whether the system will be a convenient security enhancement or a source of new risks.
The first architectural option is local processing on the device. In this scenario, the template is stored in a secure user environment, for example in the hardware security module, and only the verification result or cryptographic confirmation is transmitted to the server. This approach reduces the area of the attack, because the organization does not accumulate a centralized base of sensitive patterns, and therefore reduces the price of possible compromise.
The second option is centralized processing on the side of the organization or vendor. It is convenient for policy management, auditing, and integration with IAM, but requires much more stringent measures to protect storage, transfer, logging and power-sharing channels. For biometrics, this is especially critical, because the pattern, even in a transformed form, remains a sensitive object, and for behavioral authentication, the value is not only the final solution, but also the array of raw telemetric traits.
The third option is hybrid architecture. In it, biometrics is used as one of the factors, but not as the only source of trust. In practice, this means a bundle of “biometry + cryptographic factor + contextual risk scoring” where the system takes into account the device, geography, time, type of operation, and the user’s behavioral profile. This approach is better suited to the principle of the least sufficient trust and allows you not to block the user with a single error of the sensor or drift of the model.
Separately, it is necessary to design the boundaries of trust. If biometrics is used on a mobile device, you should determine where the trust in the OS and the hardware module ends, and where the control from the application begins. If a server check is used, it is necessary to separate the collection, storage, matching and decision-making contours so that the compromise of one segment does not open access to the entire system.
For behavioral authentication, the presence of an adaptive model is critical. The user's behavior changes due to a new device, remote work, an injury to the hand, a change of habits or just a new scenario of using the system. Therefore, the model should not only issue scoring, but also be able to work with sensitivity thresholds, retraining windows and manual validation of disputed cases. Otherwise, the system will either begin to massively mistakenly reject legitimate users, or lose meaning as a protection mechanism.
Finally, in architecture it is necessary to determine the folback mechanisms in advance. Biometrics should not be the only way to access. The standby path should include an alternative factor, a recovery procedure, and an understandable model of escalation for the support service. This is important not only for convenience, but also for security: if the failure of the main channel cannot be safely processed, users will begin to bypass protection or create unauthorized exceptions.
Threats and vulnerabilities
One of the main threats to biometrics is attacks, that is, attacks in which an attacker tries to deceive the sensor during the presentation of a biometric feature. This includes fake prints, masks, photos, screens with image playback and other ways to deceive the sensor; it is for such cases that ISO/IEC 30107 describes the approaches to presentation attack detection, or PAD, that is, the automatic detection of counterfeiting when the feature is captured.
Behavioral authentication has different risks. First, distorted data can fall into the profile, which makes the model worse distinguish between normal and suspicious behavior. Secondly, it is possible to simulate behavior when the attacker tries to reproduce the characteristics of the user. Thirdly, over time, the quality of the models decreases: the user's habits change, and without regular adjustment, the number of false failures and false tolerances increases.
The risks of template leakage should be taken into account separately. Even if the system does not store the original image of the face or fingerprint, the template itself may be sensitive: with insufficient protection, information recovery, the comparison of profiles between systems and the reuse of data in circumvention of the original purpose of processing are possible. Therefore, architecture should be evaluated not only by the accuracy of recognition, but also by the ability to protect the biometric or behavioral footprint itself.
Law and regulation
In the Russian model of regulation, biometrics is considered as a special area of personal data, and if it is used to establish identity, it falls under the regime of biometric personal data under Article 11 152-FZ. The practical conclusion is that it is not enough for an organization to simply “collect a photo or a voice”: it is important whether this information is used to identify or authenticate a person.
As a general rule, the processing of biometric personal data is allowed only with the written consent of the subject, and in a number of cases expressly listed by law - without it, for example, in connection with justice, execution of judicial acts, compulsory fingerprinting or other grounds provided by law. For business, this means that standard ACMS scenarios (access control system), login to an application or confirmation of an operation usually require a written consent form, and not just a checkmark in the interface.
Since June 1, 2023, the Russian Federation has a special regime for identification and authentication using biometrics within the framework of Law No. 572-FZ, as well as by-laws on accreditation and the procedure for processing biometric data. For practice, this is important for two reasons: firstly, a circle of permissible participants and procedures is defined, secondly, some of the biometric scenarios are now tied to the Unified Biometric System and commercial biometric systems operating in accordance with the established procedure.
This is followed by a key limitation: not all biometrics processing in a commercial system is permissible in an arbitrary form. If an organization builds a service on a person’s photo or voice for identification or authentication, it must check whether the scenario falls within the requirements of Law 572‐FZ, whether access is needed through the EBS (Unified Biometric System), whether accreditation is required, and whether the processing does not apply to the exceptions provided by law. For architecture, this means that legal scrutiny must proceed before technical implementation, not after.
Separately, it should be taken into account that the provision of biometrics should not become mandatory unless the law explicitly requires otherwise. The explanations for 152-FZ note that the refusal of a citizen to provide biometrics or consent to its processing should not automatically entail a refusal of the service, if there is no special legitimate obligation to use biometric data for such service. For the product team, this means the need for an alternative entry scenario and equivalent access to the service.
The written consent regime is also important. In 2025, the law on personal data was amended, according to which consent to the processing of personal data should be obtained separately from other documents and information; this strengthens the requirement for separate consent and reduces the risk of “hidden” consent in user documents. For biometrics, this is especially significant, because consent must not only be separate, but also in shape to correspond to the level of data sensitivity.
For employers and ACS scenarios, this means even more rigorous verification. If the photo of the employee is used to control access, Roskomnadzor considers such information as biometric personal data, and written consent is required under the rules of Article 9 and Article 11 152-FZ. In other words, the photo on the skip itself can be ordinary personal data, but as soon as it begins to be used for automatic identification, a special mode is switched on.
Finally, the design should take into account the requirements for the notification of Roskomnadzor, the purposes of processing, localization of data and the security of personal data processing in general. Even if a specific biometric scenario is legal, the organization is still obliged to define the purposes, categories of data, retention periods, the composition of protection measures, the powers of employees and the conditions for termination of processing. Therefore, the documentation should not only have policy and consent, but also clearly fixed the purpose of processing, legal basis, technical implementation, retention period and data removal procedure.
Ethical risks
The ethical problem of biometrics is not only the technology itself, but also in the context of its application. If the user cannot refuse biometrics without losing access to a meaningful service, formal consent ceases to be completely free and becomes disputed in terms of trust and integrity. Therefore, it becomes mandatory to have an understandable alternative: PIN, hardware key, backup code or other way to confirm identity.
Another important risk is the shift in recognition between user groups. For facial, voice, or behavioral pattern recognition systems, this means possible errors in people of different ages, gender, health status, or features of the device. Such mistakes quickly turn from a technical problem into an ethical one if they result in unjustified refusals, blockages or discrimination.
Finally, continuous behavioral authentication can be perceived as constant observation. Even if the system is needed to protect against session capture or insider activity, the user may perceive it as too deep an analysis of their digital activity without sufficient transparency. For this reason, transparent notification and explanation of the logic of processing become not a supplement, but part of the security system itself.
Protection practices
The most reliable approach involves protecting templates and minimizing data. Protective mechanisms for biometrics should prevent direct storage of the original image and reduce the risk of recovery or comparison between systems. For behavioral data, this is achieved through aggregation, pseudonymization and limitation of trait detail.
To protect against presentation attacks, you need to introduce PAD mechanisms and check them according to formal criteria, not according to the supplier's statements. ISO/IEC 30107-3 sets the basic principles of testing and reporting for such mechanisms, that is, a description of the test scenario, the results metrics, the thresholds of acceptance and the format of the presentation of the results. This is convenient to use as a basis for the requirements for the vendor and internal acceptance of the solution.
For behavioral authentication, model protection, control of changes in user behavior and data validation are important. It is useful to save not only the final scoring, but also the version of the model, the thresholds, the reason for the decision and the history of the changes, so that you can explain why access was allowed or blocked.
Metrics and Quality
It is necessary to assess such systems not only by convenience, but also by clear safety metrics. For biometrics, FARs are traditionally used – a share of false tolerances, FRR – a fraction of false failures and an EER – the point of equal error when FAR and FRR approximately coincide. These indicators help to see a real compromise between security and convenience, rather than relying on subjective impressions.
At the same time, low FAR does not always mean a good solution. If the system is too rigid, the FRR grows, users start to bypass the protection, and the support service receives a stream of calls. Therefore, metrics need to be associated with business processes: entry time, the number of calls for access recovery, the number of blockages and the percentage of successful repeated attempts.
For behavioral authentication, it is useful to measure the stability of the profile over time. If the model is “outdated” too quickly, the system will either mistakenly reject legitimate users or loosen controls to an ineffective level. That is why piloting is better carried out not in the laboratory, but on a real user flow with control of thresholds and logging of errors.
Life cycle of data
The most underrated aspect is the life cycle of biometric and behavioral data. At the collection stage, the objectives, list of features, shelf life and disposal procedure should be defined. At the stage of operation, access control is needed,
encryption, logging, and regular verification that data is not used beyond the stated purpose.
For the user, it is necessary to provide a clear mechanism for revocation of consent, removal of the template and transition to an alternative method of entry. In systems where biometrics is stored locally, it is usually easier; in centralized platforms, it is more important to eliminate dependence on a single provider and determine in advance how migration or data removal is performed. For behavioral authentication, another task is added: the removal of the history of behavior should be technically and organizationally enforceable, not just declared.
Logs also require caution. If the original biometric images, raw behavioral events or detailed features remain in the journal, the system creates a secondary array of sensitive data. Therefore, in the logs it is better to store event identifiers, the model version, the result of verification and the technical context, rather than the complete biometric routes.
Road map of implementation
Step-by-step implementation is not to start with the choice of a vendor, but with the classification of the scenario: what exactly is protected, what type of data is used, where the processing will take place and whether the organization has a legitimate basis for such a regime. Then the risk assessment, the choice of architecture, legal verification and only after that – piloting. Such an order is necessary to avoid a situation where a technically correct solution is unsuitable due to regulatory restrictions.
At the stage of preparation, it is useful to fix the initial conditions: the type of biometrics or behavioral data, the role of the mechanism in authentication, the availability of an alternative entry method, the format of consent, storage requirements and the boundaries of the responsibility of the vendor and the operator. This will be the basis for the subsequent implementation table: it will be convenient to break the stage, purpose, input artifacts, responsible, control points and completion criteria.
Further, logic is usually built as follows: first, a legal and architectural model is formed, then a pilot is carried out on a limited group, after which accuracy metrics, failure rate, support load and resistance to errors and attacks are checked. Already as a result of the pilot, you can proceed to scaling, but only if there are approved procedures for restoring access, logging, responding to incidents and deleting data.
