Multi-Factor Authorization (MFAz)

Updated 7 July 2026

MFAz is a multi-factor authorization scheme that extends traditional MFA by using historical access data and fine-grained rules to secure ongoing requests.
It employs verification points derived from past valid accesses, ensuring that each request is re-authorized beyond the initial login.
The system integrates Bloom filters and blockchain technology to enable efficient, tamper-proof verification in dynamic environments.

Multi-Factor Authorization (MFAz) denotes a multi-factor authorization scheme in which access is not decided solely by identity verification at login, but by multiple authorization conditions applied to the request itself. In its first formal introduction, MFAz is presented as a scheme “orthogonal to the multi-factor authentication (MFA) schemes,” motivated by the observation that unauthorized access increasingly arises not only from weak access-control policies but also from advanced exploitation strategies such as session hijacking. In the historical-access formulation, MFAz uses fine-grained access control rules (ARs) and verification points (VPs) generated from historically granted accesses as two authorization factors, with Bloom filters and blockchain used to support efficient and tamper-proof verification (Chekole et al., 21 Jul 2025).

1. Conceptual placement

MFAz is defined against a background in which MFA is already known to be highly effective at the authentication stage, but insufficient for some post-authentication threats. In a large study of suspicious commercial Microsoft Azure Active Directory activity, MFA kept over 99.99% of MFA-enabled accounts secure during the investigation period, reduced compromise risk by 99.22% across the entire population, and reduced compromise risk by 98.56% in cases of leaked credentials (Meyer et al., 2023). The historical-access MFAz proposal does not dispute those results; rather, it argues that MFA protects the authentication stage, whereas session hijacking targets an already established session, making a separate authorization mechanism necessary (Chekole et al., 21 Jul 2025).

Dimension	MFA	MFAz
Primary stage	authentication stage	after or during access control
Typical factors	additional verification steps; “what you have” and “what you know”	fine-grained access control rules and verification points
Central motivating threat	leaked credentials, suspicious activity, MFA bombing	weak access control policies and session hijacking

This distinction is central. MFA asks whether the claimant should be admitted; MFAz asks whether an already submitted request should still be authorized. The MFAz paper therefore frames authorization as a continuing security boundary rather than a one-time consequence of successful login. A plausible implication is that MFAz belongs to the same family as step-up and context-sensitive controls, but it operates at a different layer than ordinary login-stage MFA.

2. Threat model and problem setting

The explicit MFAz threat model separates two classes of unauthorized access. The first consists of conventional access-control failures, including weak access control policies, broken access control, misconfigured systems, insecure access-control methods, identifier-based functions, and multistage functions. The second consists of advanced threats, above all active session hijacking, in which an unauthorized user takes over an existing authenticated session between an authorized user and the server (Chekole et al., 21 Jul 2025).

The attacker model is concrete. Once an attacker obtains the session identifier (SID), the attacker can perform a replay attack using the stolen SID and send requests to the server as if they were the legitimate user. The paper explicitly considers session fixation, cross-site scripting (XSS), and brute forcing as ways to obtain the SID. It also states that communication is secured with SSL/TLS or similar protocols, so sniffing-based sidejacking is not assumed in the final model. The focus is therefore not on preventing SID theft itself, but on preventing successful use of a hijacked session for authorization (Chekole et al., 21 Jul 2025).

This threat framing complements adjacent work on credential theft and MFA abuse. In single sign-on environments, the token-based TULIP architecture attempts to stop credential-based attacks and MFA bombing by rendering the login page only if the browser presents a valid enrollment JWT; if the JWT is missing, invalid, revoked, or mismatched, the login page is not shown (Hays et al., 2024). TULIP moves the trust boundary in front of the login page, whereas MFAz moves an additional trust boundary into the authorization path after session establishment. This suggests a layered model in which pre-login device enrollment and post-login multi-factor authorization address different parts of the attack surface.

3. Formal structure: historical access as an authorization factor

The formal structure of MFAz is two-factor. The first authorization factor is a set of fine-grained access rules (ARs); the second authorization factor is a set of verification points (VPs) derived from historically granted accesses. The notation introduced for the scheme includes $AU$ for authorized user, $UU$ for unauthorized user, $U_i$ for user $i$ , $O_i$ for operation $i$ , $R_i$ for resource $i$ , $GA_i$ for historical granted accesses of user $i$ , $UU$ 0 for the $UU$ 1 session of $UU$ 2, $UU$ 3 for a randomly selected set of granted accesses, $UU$ 4 for verification point, $UU$ 5 for the user’s long-term authentication key, $UU$ 6 for timestamp, and $UU$ 7 for a cryptographic hash function (Chekole et al., 21 Jul 2025).

ARs are described as fine-grained access control rules based on attribute-based access control. Their operational role is represented by:

$UU$ 8

which returns 1 if the rules are satisfied and 0 otherwise. VPs are generated from historical access data and the user’s key material. The core generation functions are:

$UU$ 9

and

$U_i$ 0

In this model, a historical granted access is itself a hashed record of a prior legitimate access, and a verification point is a derived authorization token computed from that record and the long-term key. The request is accepted only if both the access rules and the VP check succeed (Chekole et al., 21 Jul 2025).

The paper organizes the system into enrollment and authorization phases. During enrollment, the user provides the long-term key $U_i$ 1 and attributes; the server initializes the user’s blockchain entry, bootstraps dummy granted accesses and dummy verification points, inserts the dummy VPs into the Bloom filter, and stores the result on blockchain. During authorization, the user sends an access request containing $U_i$ 2, $U_i$ 3, $U_i$ 4, and a small list of randomly selected historical granted accesses $U_i$ 5. The server checks the ARs, fetches the latest Bloom filter from blockchain, computes a temporary VP from the supplied $U_i$ 6 and $U_i$ 7, checks Bloom-filter membership, and, if the VP is present, grants access and generates a new $U_i$ 8 and $U_i$ 9 for future use (Chekole et al., 21 Jul 2025).

The named primitives are correspondingly simple: SatAR, GenGA, GenVP, CheckVP, InsertVP, VerifyVP, StoreBF, and FetchBF. The conceptual effect is that possession of a stolen session token alone is not sufficient; the attacker must also satisfy a historical-access-based verification condition.

4. Bloom filters, blockchain, and empirical evaluation

The MFAz proof-of-concept uses a Bloom filter to store verification points efficiently and blockchain to make authorization state tamper-proof and decentralized. The Bloom filter is initialized for approximately 1000 entries with a 1% false positive rate, yielding about 9585 bits and 7 hash functions. Because each VP is a 32-byte SHA-256 hash output, 1000 VP entries would require 32,000 bytes without a Bloom filter, whereas the reported Bloom-filter implementation uses 1255 bytes total: 1199 bytes for the bit array and 56 bytes for the Bloom-filter structure (Chekole et al., 21 Jul 2025).

Blockchain is used to store ARs and the Bloom filter containing VPs. The paper attributes to this design distributed storage, immutability, tamper-proofing, transparency, decentralization, high availability, and no single point of failure. In the reported smart-city / IIoT testbed, the implementation uses C/C++, the MIRACL cryptography library, SHA-256, and Ganache as a local blockchain testnet, with HTTP/HTTPS, TCP, UDP, and MQTT in the communication environment. The testbed devices are an ADLINK MVP-510A gateway, a Dell XPS 13 9315 PC, and a Raspberry Pi 4 Model B (Chekole et al., 21 Jul 2025).

Security evaluation is reported against both conventional access-control attacks and session hijacking. With valid and invalid user attributes and access rules, legitimate requests were accepted and malicious attempts were denied, with no errors observed. Against session hijacking, the system was tested with real and fake SIDs and with combinations of real and fake granted accesses; all malicious attempts were denied, all legitimate attempts were accepted, and no false positives or false negatives were observed in the reported experiments (Chekole et al., 21 Jul 2025).

The runtime results show that VP checking is fast and that blockchain interaction is the dominant cost.

Device	VP generation total (ms)	VP verification total (ms)
Gateway	0.5343	0.9199
PC	1.07887	1.27186
RPi	4.54106	4.09913

The component breakdown reported in the paper attributes generation time to VP computation, VP insertion to the Bloom filter, and Bloom-filter storing to blockchain, while verification time is attributed to Bloom-filter fetching from blockchain and VP checking. The dominant cost is blockchain interaction, especially Bloom-filter storage and fetching, whereas VP computation and checking are much smaller (Chekole et al., 21 Jul 2025).

Although MFAz is introduced as the first formal multi-factor authorization scheme, several earlier or parallel systems exhibit adjacent design patterns. One direct precursor is a blockchain-based approach for SMS and USSD transaction security, where a profile of how a user performs transactions is built over time and analyzed with a Bayesian Network; if a transaction’s risk exceeds multiFactorThreshold, the system generates additional authentication questions from previously endorsed blockchain transactions (Kinai et al., 2020). That system is described as adaptive and workflow-integrated, and it uses historical transaction evidence as a factor. It does not use the AR/VP formalization of historical-access MFAz, but it clearly anticipates the broader idea that past granted actions can serve as authorization evidence.

A second adjacent line appears in mobile payments. The proposed secure mobile payment architecture distributes factor validation across funds verification, biometric verification, location verification, and other optional verification nodes. The final authorization decision is made only after all required nodes report their status to the card network, and the paper explicitly characterizes the design as a distributed MFAz model (Alamleh et al., 2023). Here, authorization combines user legitimacy, contextual plausibility, and financial feasibility rather than relying on a single wallet token.

A third adjacent formulation is the M2I framework for IoT, which links Level of Assurance (LoA) to resource sensitivity and interaction mode. M2I introduces an authorization block with an Access Control Function and an Access Decision Function, defines a Required Level of Assurance (RLoA) for devices, and grants access only if the achieved assurance is at least the required assurance. It also reports that the O2M interaction mode reduces communication cost by 42%–45% compared with Kerberos and that the P2P and O2M protocols reduce the computational cost by 70%–72% and 81%–82%, respectively (AlJanah et al., 2022). M2I is still framed as authentication, but it shows how assurance values can become direct policy inputs for access decisions.

Other research explores alternative factor combinations without formalizing historical-access authorization. A passwordless BLE/NFC scheme combines a real-time face biometric with a BLE/NFC-enabled smartphone as an ownership and proximity factor, using NFC tap and Bluetooth proximity to complete login (Shukla et al., 2024). A four-factor mobile transaction design combines login-password, OTP, geolocation, and facial recognition, then packages the resulting authentication data into an image using the Babushka / Matryoschka approach (Jain et al., 2023). These systems illustrate that the research space surrounding MFAz is broad: some works bind multiple factors to a transaction, some to a device, some to an interaction context, and the formal MFAz proposal isolates authorization itself as the locus of factor composition.

6. Design tensions, operational issues, and broader significance

The broader MFA literature shows that simply adding factors does not guarantee secure deployment. A systematic security analysis of MFA protocols proposes eight evaluation criteria—mutual authentication, distinctiveness of factors, independence of factors, leakage resilience, perfect forward secrecy, user anonymity, resilience against known attacks, and adversary assumption—and finds critical vulnerabilities in ten analyzed protocols (Wee et al., 2024). This is directly relevant to MFAz. The historical-access MFAz design separates ARs from VPs, which suggests a two-factor authorization structure with differentiated roles, but the general warning remains: multiplicity alone is not sufficient if the factors are poorly composed or the adversary model is unrealistic.

Operational research on MFA also identifies persistent usability and recovery failures. Large-scale review mining of app-based MFA reports that negative sentiments (56.9%) overpowered positive yet generic connotations, with major problems in initial configuration, system-design understanding, limited device compatibility, and risk trade-offs (Das et al., 2019). Hands-on testing of MFA recovery procedures shows that many websites deploy insecure recovery flows and that access to the associated email inbox was sufficient in most successful recovery cases, allowing attackers to circumvent or disable MFA (Amft et al., 2023). Survey-based analysis of Google and Apple accounts further shows that many users would lose access if they lose a single authentication device, with 17 Apple users and 10 Google users in the sample at that highest lock-out risk (Büttner et al., 2024).

These results concern MFA rather than MFAz, but they matter for the deployment context of authorization factors. The historical-access MFAz proposal assumes that historical granted accesses are securely stored in the user’s device and that ARs and VPs are stored on blockchain (Chekole et al., 21 Jul 2025). A plausible implication is that any practical MFAz deployment will need to treat storage, migration, backup, and operational communication with the same care that MFA deployment studies identify for login factors and recovery channels. Another plausible implication is that, because MFAz is described as orthogonal to MFA, it is best understood not as a replacement for strong authentication but as an additional authorization layer for cases in which successful login does not exhaust the security problem.

In that sense, MFAz marks a conceptual shift. Traditional MFA primarily strengthens the answer to “who is requesting access?” Historical-access MFAz adds a structured answer to “should this specific request still be authorized, given policy and prior legitimate access history?” The importance of that distinction grows in environments where session hijacking, replay of valid session identifiers, and post-authentication abuse are material threats.