Shared Use in Federated Authentication: Making a Real-World Usage Condition Explicit

The security semantics of declared non-exclusive use in a person-bound identity system

The planned Shared Use declaration for AGOV Business Accounts represents one narrowly defined aspect of this problem. An AGOV account continues to represent exactly one natural person, while the holder of a Business Account may declare that the account is used non-exclusively. AGOV can communicate that declaration to a target application as shared_use=true. The declaration concerns the account's usage context rather than the identity or authority of a particular operator; its absence is correspondingly not a verified statement of exclusive use.

This article examines the legal boundaries and security significance of that signal. The generally applicable federal IAM and administrative-procedure provisions considered here do not establish a categorical prohibition of non-exclusive account operation, while transaction-specific legal and access requirements remain fully applicable. Contemporary authentication guidance recognises that strong authenticators can substantially resist unauthorised compromise without preventing deliberate cooperation by their legitimate holder. Human-centred security research likewise cautions against treating prescribed behaviour as an empirical description of every operating situation. Shared Use makes a declared non-exclusive usage context available as an additional input to security policy and can also allow the account holder to protect highly personal functions from use through that context. Its presence may justify additional controls, while its absence must not be interpreted as evidence that sharing does not occur. The distinction has concrete consequences for highly person-bound attributes, delegation, access control and individual accountability.

1. Account subject and human operator are distinct propositions

The identity represented by the account must nevertheless be distinguished from the identity of the human being operating an authentication mechanism during a particular transaction. Let A denote the natural person represented by the account and O the human operator. Under ordinary personal use, O = A. Assignment of the account to A, however, does not by itself make this equality a technically invariant property of every future authentication event.

NIST SP 800-63B-4 describes authentication as establishing that a claimant controls one or more authenticators associated with a subscriber account. Authentication Assurance Levels express increasing confidence in that control.1 Identity proofing addresses the association of a real-world subject with a digital identity, while authorisation determines what an authenticated subject may do within a particular application. These propositions interact, but they are not interchangeable.

A successful authentication can therefore provide evidence concerning control of authenticators bound to A's account without independently establishing the legal authority of the actor or excluding every form of deliberate cooperation by the legitimate holder. Shared Use concerns the latter circumstance. It does not alter who the account represents; it records information about the declared way in which the account is operated.

2. The precise scope of Shared Use

The assertion is account-level rather than transaction-level. It describes a declared non-exclusive usage model and does not establish whether A or another person performs the current transaction. No additional account subject is thereby created, and the Business Account continues to represent the same natural person.12

Nor does the declaration encode a relationship between A and any other operator. Questions of employment, organisational affiliation, representation, signing authority and application-specific permissions remain matters for the relevant target systems.11,12,13

The signal is asymmetric. Where Shared Use has been declared, AGOV can communicate shared_use=true. Where it has not been declared, AGOV has not verified the opposite proposition. The absence of the signal is therefore not evidence of shared_use=false and cannot be used to certify exclusive operation.

AGOV's terms of use reinforce the distinction between account identity and operating practice. They require account holders to ensure that their login factors are accessible only to them, while also specifying that, if those factors are nevertheless made accessible to others, the account and its logins continue to represent the account holder and responsibility remains with that person.14

The relevant semantic content of Shared Use is consequently compact: the account holder has positively declared non-exclusive use of a person-bound Business Account. Everything that follows in the architecture must remain within the limits of that proposition.

3. Legal assessment

The federal IAM provisions examined here do not establish a categorical rule requiring every authentication event to be operated personally by the natural person represented by the account. Article 3 paragraph 3 IAMV describes the IAM system as an upstream system that verifies identity and properties relevant to authorisation and communicates the result to the downstream information system so that the latter can determine permissions. Article 5 paragraph 5 leaves responsibility for the downstream system, particularly for access to it, with the competent specialist authority. Article 16 governs authentication and the transmission of verified identity information and other defined properties in connection with an individual access event.9

These provisions describe the role of the IAM layer and the allocation of responsibility between that layer and the downstream system. They do not regulate Shared Use specifically and should not be read as positively authorising the transfer or joint use of authentication factors.

Federal administrative procedure provides a separate point of reference. Article 11 paragraph 1 VwVG provides that a party may be represented at any stage of proceedings unless the party is required to act personally.10 This provision likewise says nothing about the sharing of authentication factors and cannot serve as a legal basis for doing so. Its significance is narrower: personal action is not a universal premise of federal administrative procedure. Whether it is required depends on the applicable procedural and substantive law.

The generally applicable provisions considered here therefore support only a restrained conclusion. They do not establish a universal federal rule under which every AGOV-supported interaction must be operated personally through authentication factors used exclusively by the account holder. They equally do not establish a general right to operate an account non-exclusively.

The Federal Chancellery's published AGOV guidance goes further in its general assessment and states that there is no general legal basis prohibiting shared use of AGOV accounts.11 The same guidance expressly reserves the legal and business requirements of individual target applications. A concrete procedure may require personal action; special legislation may impose requirements concerning confidentiality, professional responsibility, representation or evidentiary attribution; and an application may impose access conditions incompatible with Shared Use.11

The resulting legal position is therefore application-sensitive. Shared Use neither changes the law governing a transaction nor answers whether another person may perform it. It provides a declared usage-context property to an architecture in which the competent downstream system remains responsible for determining the consequences of that property.

4. Why representing the usage context can matter

Strong hardware-bound authentication does not remove that boundary. A non-exportable cryptographic secret can be resistant to extraction and remote duplication while the device containing it is deliberately made available to another person. A physical security key can be handed over, or an authentication request can be approved for another operator. Resistance to unauthorised compromise and exclusivity of human operation are therefore distinct properties.

AGOV's own documentation recognises the practical consequence: the service cannot generally determine which natural person is operating the digital device at the moment of a particular transaction.11 A Shared Use declaration does not solve that identification problem. It adds information about a declared operating condition.

Human-centred security research supplies a complementary reason for representing such conditions rather than inferring actual behaviour from policy alone. Adams and Sasse showed that authentication practices develop within practical and organisational settings.3 Beautement, Sasse and Wonham described the finite "compliance budget" available when security requirements compete with primary work,4 while Herley analysed circumstances in which the immediate costs of security compliance can be more salient to users than uncertain or externalised benefits.7 Empirical work on credential sharing and "shadow security" further demonstrates that prescribed and actual security practices may diverge.5,6 Resilience Engineering captures the same methodological distinction through Work-as-Imagined and Work-as-Done.8

The medical-practice example used in AGOV's own documentation makes the problem concrete. A physician may be the natural person represented by a Business Account, while medical practice assistants perform administrative e-government work in the day-to-day operation of the practice on the physician's behalf.11 The example does not establish that such operation is legally permissible for every service. Its value is that it exposes the architectural question. A routine administrative process may have different requirements from a transaction that must personally be performed by the physician.

Without information about the usage context, both situations can reach a relying party through the same person-bound account. A positive Shared Use declaration gives the target system an additional fact on which it can condition its policy where the distinction is material.

5. Shared Use and delegation solve different problems

Shared Use communicates that a Business Account has a declared non-exclusive usage model. It does not identify another actor or describe that actor's authority. A delegation mechanism can instead represent at least two distinct subjects: the principal on whose behalf an action is performed and the person who actually performs it. Depending on the application, it may also represent the scope and duration of the authority conferred.

AGOV's terms of use assign representation and delegation mechanisms to the target systems rather than to AGOV itself.14 This allocation reflects the domain-specific character of such authority. Whether somebody may file a declaration, administer a professional process, act for a company or access particular information cannot be inferred universally by an authentication service.

This explains why Shared Use can have a function even where no general AGOV delegation service exists. Shared Use provides a common federated statement about the account's declared usage context; delegation describes who may act for whom and under which conditions.

Where actor identity and authority are material to the transaction, explicit authentication of the acting person combined with an appropriate delegation or representation mechanism is the stronger model. In the medical-practice example, an application that requires reliable attribution to the medical practice assistant should authenticate that person under their own identity and establish the authority to act separately. Shared Use should not be used to infer such a relationship indirectly.

Where the application does not require actor-level attribution but nevertheless needs to know that a person-bound account may be operated non-exclusively, Shared Use can supply that narrower context.

6. Policy consequences: asymmetry, incentives and person-bound attributes

The epistemic consequence should be reflected directly in policy. A positive Shared Use signal may justify an additional or different control because it supplies information that was not otherwise available. The absence of the signal must not justify relaxing controls that apply in the ordinary case, because non-declaration is not evidence of exclusive use. Shared Use should therefore operate as a one-sided contextual signal: its presence can affect policy; its absence leaves the baseline security model unchanged.

This rule does not solve undeclared sharing, but it avoids creating a false population of supposedly verified "non-shared" accounts.

The incentive problem is not necessarily one-directional. If declaring Shared Use rendered an account universally unusable while identical undeclared behaviour remained technically possible and functional, disclosure would impose a predictable cost specifically on users who report the condition. Research on security compliance provides reason to take such incentives seriously.4,5,7

At the same time, an account holder may have a direct security interest in declaring Shared Use precisely because the signal can cause highly personal functions to become unavailable through the shared operating context. A relying party handling particularly private matters - for example, access to the account holder's personal tax return - could restrict or refuse access when shared_use=true is present. In such a case, the resulting restriction would serve not only the relying party's risk policy but also the account holder's own interest in ensuring that personal transactions do not silently remain accessible through an account that has been declared for non-exclusive use.

This creates a positive disclosure incentive that is distinct from regulatory or organisational compliance. A person who intentionally uses a Business Account in a shared operating context may prefer sensitive personal services to recognise that circumstance and deny access rather than treat the account as though it were being operated exclusively. Shared Use can therefore function, in appropriate applications, as a form of self-protective contextual signalling.

The appropriate policy is consequently neither universal acceptance nor universal rejection. Where personal execution is required, a target application may reject the Shared Use context. Where actor identity is required, it may direct the user towards an explicit delegation model. Where non-exclusive operation has no material consequence, the signal need not alter the transaction. Consequences should follow from the significance of the declared condition to the service.

Highly person-bound attributes present a related problem at the identity-provider layer. An attribute verified for A remains an attribute of A when Shared Use is declared. What changes is the declared possibility that current operator O is another person.

The Swiss OASI number - the AHV number - is a particularly clear example. It is directly associated with the natural person represented by the AGOV account. Shared Use does not make that association incorrect, but ordinary availability of the number within a non-exclusively operated account can create an undesirable semantic coupling between a highly person-specific identifier and transactions for which AGOV does not determine the current human operator.

The published AGOV concept already anticipates this problem. It states that the Federal Chancellery may define consequences for particularly personal attributes in a Shared Use context and explicitly identifies the OASI number as an example. Such consequences may include preventing particular attributes from being stored or used for Shared Use accounts.11

That points towards a concrete design direction. Once Shared Use is active, the OASI number should normally no longer remain available as an ordinary stored account attribute that can participate in subsequent authentication transactions. At minimum, it should not be released or used while Shared Use remains declared. This is a design conclusion rather than a rule already established by the published specification, and the precise lifecycle treatment - whether removal, suspension, non-release or renewed acquisition after Shared Use is withdrawn - remains to be determined.

The reason for preferring such treatment is not that the OASI number has become inaccurate. It remains the correct identifier of A. The problem is that its continued operational availability in a declared non-exclusive account creates a risk that systems or processes attribute a strongly person-bound identifier to an interaction whose actual human operator AGOV does not establish.

Handling the attribute at the identity-provider layer also avoids placing the entire semantic burden on every relying party. Shared Use can therefore have consequences both downstream, through application-specific access policy, and upstream, through restrictions on person-bound account attributes whose ordinary use presupposes a stronger relationship between account subject and operator.

7. Accountability, residual uncertainty and evaluation

Where the identity of the actual actor is itself a required fact, the architecture needs something stronger than Shared Use: personal authentication by A, separate authentication of another actor, an explicit delegation relationship, or rejection of the Shared Use context. The appropriate mechanism depends on the application.

Residual uncertainty remains on the opposite side as well. An account without a declaration may still be used non-exclusively. The one-sided policy rule prevents that uncertainty from being hidden behind a false negative assertion, but it cannot determine the prevalence of undeclared sharing or remove incentives to conceal it entirely.

The operational value of the feature should therefore be measured after deployment. Evaluation should distinguish declaration prevalence from actual prevalence and examine whether the signal changes decisions that matter: treatment of person-bound attributes, personal authentication requirements, use of delegation, access restrictions and audit interpretation. It should also test the incentive assumption directly by examining whether different downstream consequences correlate with declaration behaviour.

The treatment of the OASI number deserves particular attention. If Shared Use results in removal, suspension or non-use of that attribute, operational evidence should establish whether the rule prevents inappropriate person-level attribution without creating incentives that materially discourage truthful declaration. Conversely, services that deliberately use shared_use=true to protect highly personal functions offer an opportunity to examine whether self-protection provides a positive incentive for truthful disclosure.

Such evaluation is important because the conceptual argument establishes the semantics and potential utility of additional information. Whether the resulting system is safer depends on the policies, user behaviour and application architectures that develop around it.

8. Conclusion

The Shared Use declaration adds one further proposition: the holder of a Business Account has declared non-exclusive use. Its value lies in making that context available without pretending that it identifies the current actor or resolves questions of representation.

The asymmetry of the signal is fundamental to its safe use. shared_use=true may justify additional or different controls; the absence of the assertion must leave baseline controls intact rather than being interpreted as proof of exclusive operation. For the account holder, the same signal can provide a means of ensuring that highly personal services do not silently remain accessible through a declared shared operating context. Where actor identity and authority are required, explicit authentication and delegation provide the stronger model.

The same principle applies to information held by AGOV itself. Highly person-bound attributes should not remain operationally available in a Shared Use context merely because they remain factually correct for the account holder. The OASI number is the clearest example: where non-exclusive use has been declared, its storage, availability and release require treatment that prevents the identifier from acquiring transaction-level significance that AGOV cannot substantiate.11

Shared Use is therefore neither a substitute for personal authentication nor a substitute for delegation. It is a deliberately one-sided contextual signal whose usefulness lies in allowing AGOV, relying parties and the account holder to respond to a declared non-exclusive usage model without treating undeclared accounts as verified exclusive-use accounts.

Shared Use makes a declared non-exclusive usage condition explicit. Where that condition matters, the architecture can respond to it; where personal attribution is required, another mechanism must establish the person who is actually acting.

References

1. National Institute of Standards and Technology. Digital Identity Guidelines: Authentication and Authenticator Management. NIST Special Publication 800-63B-4. Gaithersburg, MD: National Institute of Standards and Technology; 2025.


2. National Institute of Standards and Technology. Security and Privacy Controls for Information Systems and Organizations. NIST Special Publication 800-53 Rev. 5. Gaithersburg, MD: National Institute of Standards and Technology; 2020, updated 2025.


3. Adams A, Sasse MA. Users are not the enemy. Communications of the ACM. 1999;42(12):40-46. doi:10.1145/322796.322806.


4. Beautement A, Sasse MA, Wonham M. The compliance budget: managing security behaviour in organisations. In: Proceedings of the 2008 New Security Paradigms Workshop. New York: Association for Computing Machinery; 2008:47-58. doi:10.1145/1595676.1595684.


5. Kirlappos I, Parkin S, Sasse MA. "Shadow security" as a tool for the learning organization. ACM SIGCAS Computers and Society. 2015;45(1):29-37. doi:10.1145/2738210.2738216.


6. Singh S, Cabraal A, Demosthenous C, Astbrink G, Furlong M. Password sharing: implications for security design based on social practice. In: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. New York: Association for Computing Machinery; 2007:895-904. doi:10.1145/1240624.1240759.


7. Herley C. So long, and no thanks for the externalities: the rational rejection of security advice by users. In: Proceedings of the 2009 New Security Paradigms Workshop. New York: Association for Computing Machinery; 2009:133-144. doi:10.1145/1719030.1719050.


8. Hollnagel E, Clay-Williams R. Work-as-Imagined and Work-as-Done. In: Rapport F, Clay-Williams R, Braithwaite J, editors. Implementation Science: The Key Concepts. London and New York: Routledge; 2022:175-177. doi:10.4324/9781003109945-52.


9. Swiss Federal Council. Ordinance of 19 October 2016 on Identity Management Systems and Directory Services of the Confederation (IAMV; SR 172.010.59), in particular Article 3 paragraph 3, Article 5 paragraph 5 and Article 16.


10. Swiss Confederation. Federal Act of 20 December 1968 on Administrative Procedure (Administrative Procedure Act, APA; SR 172.021), in particular Article 11 paragraph 1.


11. Swiss Federal Chancellery. AGOV: Questions and Answers, in particular FAQ 1.14 "Is it prohibited to give my AGOV login to other people?" and FAQ 1.28 "Do AGOV Business Accounts and an optional 'Shared Use' declaration weaken the link between an AGOV account and a natural person?" Accessed 1 October 2026.


12. Swiss Federal Chancellery. AGOV Help: Legal entities. In particular the sections on person binding, organisational authority and Shared Use. Accessed 1 October 2026.


13. Swiss Federal Chancellery. AGOV in Business. Accessed 1 October 2026.


14. Swiss Federal Chancellery. AGOV Terms of Use for End Users. In particular the provisions on personal assignment of accounts, responsibility for login factors and delegation mechanisms. Accessed 1 October 2026.