Access Control Integration in Sparkplug-Based Industrial Internet of

Things Systems: Requirements and Open Challenges

Pietro Colombo

and Elena Ferrari

Department of Theoretical and Applied Science, University of Insubria, Via O. Rossi, 9 - 21100 Varese, Italy

{pietro.colombo, elena.ferrari}@uninsubria.it

Keywords:

Industrial Internet of Things, Sparkplug, MQTT, Fine-Grained Access Control, Access Control Policies.

Abstract:

Sparkplug (ISO, 2023) is an emerging open-source software speciﬁcation that supports integrating applications

and devices in Industrial Internet of Things (IIoT) systems and eases data integration. Although recently

introduced, Sparkplug has rapidly gained popularity, and its speciﬁcations have already been deﬁned as an

ISO standard. However, the basic data protection features it supports could hinder the adoption of Sparkplug

on a large scale. Efﬁcient access control solutions for Sparkplug-based IIoT systems open new research

challenges. In this position paper, we take the ﬁrst step to ﬁll this void by presenting key requirements for

integrating access control into Sparkplug systems and discussing signiﬁcant issues for developing a suitable

access control framework.

1 INTRODUCTION

Industrial Internet of Things (IIoT) is an emerg-

ing paradigm that combines IoT technologies and

real-time data analytics to enable device connectiv-

ity, favor faster business decisions, and maximize

revenue growth (Ahmed et al., 2023; Boyes et al.,

2018). Recent surveys claim that manifold industrial

ﬁelds beneﬁt from IIoT technologies and that the

IIoT market is rapidly expanding. See, for instance,

https://www.grandviewresearch.com/industry-

analysis/industrial-internet-of-things-iiot-market).

A key issue for the IIoT domain is the interop-

erability of applications and heterogeneous mission-

critical devices from different vendors that charac-

terize an industrial environment (Hazra et al., 2021),

which can be addressed by relying on a standard com-

munication protocol.

In recent years, MQTT (OASIS, 2019) has be-

come a reference communication protocol for IoT ap-

plications. MQTT is often used in IIoT frameworks

as the adopted topic-based publish/subscribe commu-

nication overcomes the limits of poll/response proto-

cols used in Industrial Control systems (Nast et al.,

2022). However, MQTT lacks a standardized data

format, leading to interoperability problems. More-

over, MQTT lacks a uniﬁed, systematic approach to

https://orcid.org/0000-0003-4617-5247

https://orcid.org/0000-0002-7312-6769

managing the state of devices, which IIoT control ap-

plications must continuously monitor.

Sparkplug (ISO, 2023) is a recent open speciﬁ-

cation designed to favor the interoperability of het-

erogeneous devices and data integration. Spark-

plug extends MQTT while maintaining compatibil-

ity with its infrastructure. Indeed, a Sparkplug sys-

tem is composed of MQTT servers and specialized

MQTT clients. Sparkplug standardizes state man-

agement and message topic structures and rules out

message payload formatting and encoding, provid-

ing vendor-neutral speciﬁcations for data formats.

Although recently proposed, Sparkplug appears as

an up-and-coming IIoT technology and has already

been standardized (ISO, 2023). However, the Spark-

plug’s diffusion might be hindered by the poor se-

curity features it provides. Critical security issues

can lead to equipment damage, regulatory problems,

and personal safety hazards. Like MQTT, Sparkplug

supports basic access control mechanisms. Spark-

plug speciﬁcation suggests using access control lists

(ACLs), relying on the MQTT server’s ability to en-

force them. However, ACLs ensure a coarse-grained

level of protection based on message topic matching.

Policies specify the read/write topics authorized to a

client, and access is granted for any message with

a compliant topic. More effective mechanisms are

needed. Access control should be enforced at a ﬁner-

grained granularity level, granting permissions based

on message properties, and the access request context.

380

Colombo, P. and Ferrari, E.

Access Control Integration in Sparkplug-Based Industrial Internet of Things Systems: Requirements and Open Challenges.

DOI: 10.5220/0013055700003825

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 20th International Conference on Web Information Systems and Technologies (WEBIST 2024), pages 380-384

ISBN: 978-989-758-718-4; ISSN: 2184-3252

Figure 1: Sparkplug system architecture.

Access control is a crucial security feature for IIoT

systems and has been thoroughly investigated (e.g.,

see Salonikias et al., 2019). Access control frame-

works for the IoT can be classiﬁed based on the char-

acteristics of the adopted access control model and the

enforcement mechanisms they use. In a large class of

frameworks, which include, for instance, the work by

Xu et al. (2018), access authorizations are material-

ized into capability tokens assigned to subjects, who

must prove their authorizations by presenting the re-

ceived token. Another framework family, which com-

prises the work by La Marra et al. (2018), grants au-

thorizations when access control conditions that re-

fer to mutable subjects, objects, and environment at-

tributes are satisﬁed. Authorizations are adapted to

attribute changes. On the other hand, access con-

trol frameworks like that proposed by Gouglidis and

Mavridis (2012), grant privileges to users via role as-

signments. Finally, frameworks such as the one pro-

posed by Han et al. (2022), authorize access when

conditions that refer to subjects, objects, and environ-

ment attributes are satisﬁed.

Despite the vast literature on access control, only

a few works have focused on integrating access con-

trol in MQTT systems (e.g., La Marra et al., 2018;

Colombo et al., 2021), and we are unaware of works

on Sparkplug. Although Sparkplug systems rely on

MQTT as base messaging technology, access con-

trol approaches for MQTT are unsuited for being

used with Sparkplug, and cannot be easily adapted

to Sparkplug systems. A new, dedicated approach

is needed, to be designed by taking into account dis-

tinctive Sparkplug features, such as the Report by Ex-

ception communication and the standardized message

payload deﬁnition (ISO, 2023). To ﬁll this void, in

this paper, we present essential requirements for inte-

grating access control in Sparkplug-enabled IIoT sys-

tems and discuss open research problems for develop-

ing an access control framework.

The remainder of the paper is organized as fol-

lows. Section 2 overviews basic Sparkplug concepts.

Section 3 introduces essential requirements for deﬁn-

ing an access control framework for Sparkplug sys-

tems. Section 4 discusses research challenges related

to the framework development, and ﬁnally, Section 5

concludes the paper.

2 SPARKPLUG

A Sparkplug system includes an MQTT server that

routes messages issued by specialized MQTT clients

operating as edge nodes with related devices, primary

and secondary applications. An example of Spark-

plug architecture is shown in Figure1. Edge nodes

are gateways for devices (such as sensors, PLCs, and

RTUs) that cannot communicate via Sparkplug. Edge

nodes allow them to communicate with the rest of the

infrastructure and control their states. Primary appli-

cations, are SCADA/IIoT hosts that monitor the state

of edge nodes and devices and issue commands in re-

sponse to a state change. Finally, secondary applica-

tions, like Manufacturing Execution Systems (MES),

Historians, and Analytics, receive and process data

generated by edge nodes and devices and possibly

send commands.

Communication among applications and edge

nodes is achieved by exchanging Sparkplug mes-

sages, namely MQTT application messages, with spe-

ciﬁc payload and topic structures. The payload of

a Sparkplug message aggregates properties referred

to as metrics that typically denote diagnostics, cur-

rent state values, and metadata. The topic of a mes-

sage speciﬁes the components to which that message

should be addressed and the message type.

Supported message types are listed in Table 1.

Access Control Integration in Sparkplug-Based Industrial Internet of Things Systems: Requirements and Open Challenges

381

Table 1: Sparkplug message types.

Message type Semantics

NBIRTH/DBIRTH Notiﬁes that an edge node/device is online. The payload metrics denote information

related to the component interface and the data it handles.

NDEATH/DDEATH Notiﬁes that an edge node/device went ofﬂine.

NDATA/DDATA Notiﬁes that one/multiple metrics handled by an edge node/device changed value.

STATE Notiﬁes a state change from online to ofﬂine or vice versa of the primary application.

NCMD/DCMD Notiﬁes the request by primary/secondary applications to modify the value of metrics

controlled by an edge node/device.

3 REQUIREMENTS

An access control framework for Sparkplug-enabled

IIoT applications should ensure ﬁne-grained access

control with customizable protection levels and a low

enforcement overhead.

State-of-the-art ﬁne-grained access control ap-

proaches for MQTT systems operate at the mes-

sage granularity level (e.g., Colombo et al., 2021).

However, in Sparkplug systems, the granularity level

should be ﬁner-grained for some message types.

NBIRTH/DBIRTH and NDATA/DDATA messages

aggregate metrics, each denoting a distinct data prop-

erty. By enforcing access control at the message

level, a Sparkplug message addressed to a rightful

subscriber is blocked or routed with all its metrics.

However, some of the metrics could be necessary for

a subject and not needed for others, and based on the

Principle of Least Privilege (Saltzer and Schroeder,

1975), subjects should receive the minimum privi-

leges to achieve their tasks. The same considerations

apply to NCMD/DCMD messages that allow multi-

ple write requests to be issued simultaneously. For in-

stance, a SCADA/IIoT host should access all the met-

rics edge nodes and devices manage and issue con-

trol signals to manage these components. In contrast,

a secondary application performing analytics should

not access the metrics allowing device control. To en-

force access control at the metrics granularity level,

authorized views of Sparkplug messages should sub-

stitute the original messages, from which the unau-

thorized metrics will be removed/obfuscated. For in-

stance, any metric that allows modifying a receiving

device’s state should be pruned out from the view of

a DCMD message issued by a secondary application.

Additionally, to favor customization, access con-

trol should consider any available information related

to the requesting subject, the protected object, and

the request context. In Sparkplug systems, the sub-

jects are referred to by identiﬁers. In contrast, met-

rics specify the timestamp at which they have been

set and can also be labeled with additional metadata.

A discretionary access control model should, there-

fore, be able to regulate subjects’ accesses based on

object and environment attributes. More precisely, to

exploit the Sparkplug mentioned above features, ac-

cess should be granted to subjects based on the satis-

faction of conditions that refer to the access request

time and metric properties. For instance, assume that

the metric property sensitivity is used to denote the

sensitivity level of the metrics. A secondary applica-

tion could be authorized to access data generated by

a device at a speciﬁc time interval, but only if none

of the metrics included in the message payloads has

been marked as sensitive.

The enforcement monitor should be implemented

in such a way as to intercept any Sparkplug mes-

sage addressed to the MQTT server and issued by the

MQTT server to edge nodes and applications. De-

pending on the applicable access control policies, the

monitor could either block the message transit or re-

move unauthorized metrics from the message payload

(if any) and consent to the transit of the derived view.

4 OPEN CHALLENGES

In this section, we discuss open research challenges

implied by the requirements presented in Section 3.

The peculiarities of Sparkplug make the speciﬁ-

cation of an access control enforcement mechanism

at the metric granularity level for the access control

model mentioned in Section 3 a challenging task. In

particular, Sparkplug recommends adopting a report-

by-exception (RbE) communication strategy to save

transmission bandwidth. According to RbE, data

and state information are only published when they

change. For instance, suppose sa is a secondary appli-

cation that subscribed to the reception of messages by

an edge node en. Suppose sa is allowed to see metric

m1 within messages published by en during the time

WEBIST 2024 - 20th International Conference on Web Information Systems and Technologies

382

intervals [t1..t2] and [t4..t5]. Based on the RbE ap-

proach, whenever m1 changes value, en publishes an

NDATA message that includes m1. During the inter-

val [t1..t2], authorized views of these NDATA mes-

sages, including m1, must be sent to sa. Suppose now

that en updates m1 at time t3 immediately after t2 but

before t4. Based on the above-mentioned policy, sa

cannot see the update at t3. However, the access is

newly allowed at t4. Therefore, at t4, sa should be

made aware of the value of m1 published by en at t3,

as it is the most recent one. An open issue is, there-

fore, to ﬁnd an efﬁcient approach to communicate the

last m1 value. One possible solution could be forc-

ing en to generate an NBIRTH message that includes

m1, with a forged NCMD message requesting the en

rebirth. However, the exempliﬁed scenario refers to a

single case of interaction, but additional cases could

be identiﬁed. A thorough analysis is therefore needed,

as well as the study of the related enforcement mech-

anisms.

Another challenge is related to policy speciﬁca-

tion. The enforcement of access control at the metric

level could cause signiﬁcant growth of the policy set

size. However, it could be reasonable to assume that

within a message payload, the sensitive metrics that

require dedicated access control policies could be a

minority. Approaches to minimizing the policy num-

ber and easing policy administration must be investi-

gated. A viable strategy could be using a policy model

that protects classes of messages satisfying a topic ﬁl-

ter with an exception list that speciﬁes the metrics to

be removed. For instance, referring to the previous

example, one could specify a policy p1 that matches

any NBIRTH and NDATA message published by en,

with an exception list that includes m1 and a condi-

tion specifying the time interval (t2..t4) and a policy

p2 with the same topic ﬁlter, an empty exception list,

and a condition always true.

Many policies could be speciﬁed for primary and

secondary applications that could subscribe to receiv-

ing data from any edge node and device in a Spark-

plug system. A key requirement is that the access

control policies that apply to an access request are

identiﬁed with minimal delay. For instance, policy re-

trieval could beneﬁt from efﬁcient in-memory NoSQL

databases like Redis (https://redis.io), which ensures

the execution of lookup-by-key operations with sub-

millisecond latency. However, data modeling strate-

gies for access control policies and indexing strategies

for such databases should be studied to minimize the

selection time of access control policies applicable to

an access request.

The efﬁciency of policy evaluation could depend

on the language employed to specify AC conditions.

It could be possible to rely on platforms like GraalVM

(https://www.graalvm.org), which allow code execu-

tion in multiple programming languages with high

performance. However, an empirical evaluation is

needed to assess the performance and to see whether

such a solution is oversized.

Finally, the enforcement monitor could ei-

ther be developed as an independent component

operating as a proxy of the MQTT server or

integrated into the MQTT server itself, exploit-

ing the leading brokers’ extensions mechanism,

like those of HiveMQ (https://www.hivemq.com),

EMQX (https://www.emqx.com) or Mosquitto

(https://mosquitto.org). Both approaches should be

studied by assessing aspects of performance and

scalability.

5 CONCLUSIONS

Despite the vast literature on access control for the

IoT domain, up to now no access control framework

has targeted Sparkplug systems.

In this paper, we take a step to ﬁll this void, pre-

senting key requirements for integrating ﬁne-grained

access control in Sparkplug-based IIoT systems and

discussing research issues to be addressed to build an

effective access control framework for this use case.

ACKNOWLEDGEMENTS

This work was supported in part by project SER-

ICS (PE00000014) under the NRRP MUR program

funded by the EU-NGEU.

REFERENCES

Ahmed, S. F., Alam, M. S. B., Hoque, M., Lameesa, A.,

Afrin, S., Farah, T., Kabir, M., Shaﬁullah, G. M., and

Muyeen, S. M. (2023). Industrial Internet of Things

enabled technologies, challenges, and future direc-

tions. Computers and Electrical Engineering, 110.

Boyes, H., Hallaq, B., Cunningham, J., and Watson, T.

(2018). The industrial internet of things (IIoT): An

analysis framework. Computers in Industry, 101.

Colombo, P., Ferrari, E., and T

umer, E. D. (2021). Regulat-

ing data sharing across MQTT environments. Journal

of Network and Computer Applications, 174.

Gouglidis, A. and Mavridis, I. (2012). DomRBAC: An ac-

cess control model for modern collaborative systems.

Computers and Security, 31(4).

Han, D., Zhu, Y., Li, D., Liang, W., Souri, A., and Li, K. C.

(2022). A Blockchain-Based Auditable Access Con-

Access Control Integration in Sparkplug-Based Industrial Internet of Things Systems: Requirements and Open Challenges

383

trol System for Private Data in Service-Centric IoT

Environments. IEEE Transactions on Industrial In-

formatics, 18(5).

Hazra, A., Adhikari, M., Amgoth, T., and Srirama, S. N.

(2021). A Comprehensive Survey on Interoperability

for IIoT: Taxonomy, Standards, and Future Directions.

ISO (2023). Sparkplug® version 3. ISO/IEC 20237:2023 -

Information technology.

La Marra, A., Martinelli, F., Mori, P., Rizos, A., and Sara-

cino, A. (2018). Introducing usage control in MQTT.

In Lecture Notes in Computer Science (including sub-

series Lecture Notes in Artiﬁcial Intelligence and Lec-

ture Notes in Bioinformatics), volume 10683 LNCS.

Nast, M., Raddatz, H., Rother, B., Golatowski, F., and Tim-

mermann, D. (2022). A Survey and Comparison of

Publish/Subscribe Protocols for the Industrial Internet

of Things (IIoT). In ACM International Conference

Proceeding Series.

OASIS (2019). MQTT Version 5.0 OASIS Standard.

Salonikias, S., Gouglidis, A., Mavridis, I., and Gritzalis,

D. (2019). Access control in the industrial internet of

things. In Alcaraz, C., editor, Security and Privacy

Trends in the Industrial Internet of Things. Advanced

Sciences and Technologies for Security Applications.

Springer, Cham.

Saltzer, J. H. and Schroeder, M. D. (1975). The Protection

of Information in Computer Systems. Proceedings of

the IEEE, 63(9).

Xu, R., Chen, Y., Blasch, E., and Chen, G. (2018).

BlendCAC: A smart contract enabled decentralized

capability-based access control mechanism for the

IoT. Computers, 7(3).

WEBIST 2024 - 20th International Conference on Web Information Systems and Technologies

384