1. Quem trata os seus dados

O AuthGuard Presence é a aplicação Android que aprova, no seu telemóvel, inícios de sessão e operações de uma organização que usa o AuthGuard. A aplicação é publicada pela Kotav International - Business and Assets, Lda (NIPC 517204738), com sede na Rua Bom Jesus de Penso, 766, 4770-813 Avidos, Portugal. Quando a organização usa o AuthGuard como serviço, é a Kotav que o opera por conta dela; quando o instala nos seus próprios servidores, é a própria organização que o opera.

A organização que lhe deu acesso (normalmente o seu empregador) decide para que usa as aprovações no telemóvel e é a responsável pelo tratamento dos dados da sua conta; a Kotav trata-os por conta dela. Para os dados de aviso (FCM, secção 4) a Google atua como subcontratante. [REVISÃO JURÍDICA] Confirmar os papéis de responsável e subcontratante e o contacto do encarregado de proteção de dados.

Contacto: privacidade@authguard.pt.

2. Que dados existem e onde ficam

2.1 Só no seu telemóvel

• Duas chaves privadas por conta, criadas no hardware seguro do telemóvel (StrongBox ou o ambiente seguro do processador). Não podem ser exportadas; a chave de aprovação só assina depois da sua biometria ou do PIN do telemóvel.
• A lista das contas ligadas: endereço do servidor, nome da organização, uma indicação parcial da conta (por exemplo j***@empresa.pt), identificadores do telemóvel no servidor, o nome do telemóvel, onde estão as chaves, o modo de confirmação, a data em que a conta foi ligada e a diferença de relógio para o servidor.
• A data do último registo do token de aviso em cada conta e, durante 10 minutos, os identificadores dos pedidos já notificados, para não repetir avisos. A aplicação não guarda o token; a biblioteca Firebase guarda o token e o identificador de instalação no armazenamento privado da aplicação.

Estes dados ficam no armazenamento privado da aplicação, excluído de cópias de segurança e de transferências entre telemóveis. A biometria nunca sai do telemóvel: a aplicação só recebe do Android a indicação de que a confirmação foi feita. A câmara serve apenas para ler o código QR de ligação; as imagens são analisadas no telemóvel e não são guardadas nem enviadas.

2.2 Enviados ao servidor AuthGuard da sua organização

• Na ligação: as duas chaves públicas, as cadeias de certificados de atestação das chaves (emitidas pelo hardware do telemóvel e assinadas pela Google), o nome do telemóvel (o modelo, por exemplo Pixel 8) e as provas de posse das chaves.
• Em cada pedido do telemóvel: uma prova assinada pela chave do telemóvel, com a hora e um identificador aleatório de uso único.
• Em cada aprovação: a decisão (aprovar, recusar ou «Não fui eu»), o código de seis algarismos que escreveu, dentro de uma declaração assinada pela chave de aprovação, e a hora.
• O token de registo do Firebase Cloud Messaging (FCM), para o servidor poder pedir à Google que acorde a aplicação.
• O endereço IP de cada pedido, usado para limitar abusos (contadores de curta duração) e registado nos registos de acesso do servidor, com a rota do pedido e sem identificar a pessoa.

O servidor guarda do telemóvel: o nome, as duas chaves públicas, um resumo da atestação (nível de segurança das chaves, modo de confirmação, nível de atualização de segurança do Android, versão da atestação, versão da aplicação e resumo SHA-256 do certificado de assinatura da aplicação), os números de série dos certificados de atestação, um resumo SHA-256 das cadeias, e as datas de ligação, confirmação, última utilização e remoção. Regista também as aprovações e recusas nos pedidos e no registo de auditoria da organização.

Todas estas comunicações usam TLS 1.3 com troca de chaves híbrida pós-quântica (X25519MLKEM768).

2.3 O que não recolhemos

A aplicação não usa publicidade, analytics, rastreio nem identificador de publicidade. Não lê contactos, localização, fotografias, ficheiros, microfone nem histórico de navegação.

3. Para que servem

• Autenticá-lo e confirmar as suas aprovações de inícios de sessão, de confirmações administrativas e de operações pedidas por outros sistemas da organização.
• Ligar cada aprovação à operação exata que viu (ProofFlow Match): o código que escreve no telemóvel tem de corresponder ao que o browser mostra.
• Verificar que as chaves estão em hardware seguro de um telemóvel não modificado e que a aplicação é a original (atestação de chaves).
• Acordar a aplicação quando há um pedido à sua espera.
• Prevenir abusos e manter a prova das decisões.

Fundamento jurídico: o definido pela sua organização, em regra a execução do contrato com ela ou o seu interesse legítimo em proteger os acessos (RGPD, artigo 6.º, n.º 1, alíneas b) e f)). [REVISÃO JURÍDICA]

4. Avisos de novos pedidos (Google Firebase Cloud Messaging)

Quando há um pedido para aprovar, o servidor pede ao Firebase Cloud Messaging, um serviço da Google, que acorde a aplicação. A mensagem é sempre a mesma, {"v":"1"}: não leva o pedido, a sua conta, a organização, o serviço, o código nem qualquer outro conteúdo, e expira ao fim de 5 minutos se não for entregue. Ao acordar, a aplicação vai buscar os pedidos diretamente ao servidor da organização, pelo canal protegido descrito acima, e mostra uma notificação que só indica o tipo de pedido.

Para isso a Google trata o token de registo FCM, o identificador de instalação Firebase, os identificadores do projeto e da aplicação e a hora e o tamanho de cada mensagem. Para emitir o token, a biblioteca Firebase e os serviços Google Play do telemóvel comunicam com a Google e enviam dados técnicos da aplicação e do sistema. O Google Analytics para Firebase está desligado e a exportação de métricas de entrega está desativada. [A CONFIRMAR NO TELEMÓVEL] Se a biblioteca enviar métricas técnicas de entrega próprias, serão declaradas aqui e no formulário de segurança dos dados do Google Play.

A Google atua como subcontratante, nos termos de tratamento de dados do Firebase (Firebase Data Processing and Security Terms, firebase.google.com/terms/data-processing-terms). Estes dados podem ser transferidos para os Estados Unidos, ao abrigo do mecanismo de transferência previsto nesses termos (Quadro de Privacidade de Dados UE-EUA ou cláusulas contratuais-tipo da Comissão Europeia). [REVISÃO JURÍDICA]

Sem conta ativa, a aplicação não pede token. Ao remover a última conta, a aplicação apaga o token e desliga a criação automática de um novo.

5. Quem recebe os dados

• A sua organização e os administradores dela, na consola AuthGuard (lista de telemóveis, estado, nível de segurança, resumo da atestação e datas; nunca as chaves privadas).
• Quando a organização usa o AuthGuard como serviço: a Kotav, que o opera, e o prestador de alojamento que a Kotav contrata, na região de dados escolhida pela organização (União Europeia, salvo se a organização escolher outra). Quando a organização instala o AuthGuard nos seus próprios servidores, os dados ficam nesses servidores e a Kotav não os recebe. [REVISÃO JURÍDICA] Nomear o prestador de alojamento do serviço em produção e o local das cópias de segurança, e avaliar a transferência se o prestador ou a região não forem europeus.
• A Google, apenas para os avisos (secção 4).

Os dados não são vendidos nem partilhados para publicidade ou para fins próprios de terceiros. A verificação de revogação das atestações descarrega a lista pública da Google sem enviar dados do seu telemóvel.

6. Durante quanto tempo

• No telemóvel: até remover a conta ou desinstalar a aplicação.
• Token FCM no servidor: apagado quando o telemóvel é removido da conta ou quando a Google indica que deixou de ser válido.
• Provas de pedido (identificadores de uso único): 10 minutos, apagadas na limpeza periódica seguinte. Desafios de aprovação: apagados depois de expirarem (no máximo 2 minutos), salvo os que suportam uma aprovação, que ficam com ela. Pedidos de ligação: 7 dias depois de terminarem.
• Registo do telemóvel no servidor, incluindo o nome, o resumo da atestação e os números de série dos certificados: enquanto a sua conta existir, também depois de o telemóvel ser removido, como prova de segurança das aprovações feitas com ele.
• Se pedir o apagamento dos seus dados (RGPD, artigo 17.º), o telemóvel é removido, o nome passa a «(removido)» e o resumo da atestação e os números de série são apagados. Ficam as chaves públicas e o resumo SHA-256 das cadeias de atestação, necessários para verificar assinaturas passadas, e o registo de auditoria, que passam a ser pseudónimos.
• Aprovações, recibos e auditoria: segundo o prazo de conservação definido pela sua organização. [REVISÃO JURÍDICA] Prazo e fundamento da conservação da prova.
• Registos de acesso do servidor (endereço IP e rota): 90 dias.
• Cópias de segurança: até 35 dias.

7. Remover este telemóvel e os seus dados

• Na aplicação: «Gerir contas» › «Remover esta conta deste telemóvel». O servidor é avisado e remove o telemóvel da conta (o token FCM é apagado), e a aplicação apaga as duas chaves e os dados locais da conta. Ao remover a última conta, apaga também o token FCM do telemóvel. Se o servidor não puder ser avisado, a aplicação diz-lhe para remover o telemóvel na consola.
• Na consola AuthGuard: em «Os meus telemóveis», depois de um início de sessão recente com um fator forte.
• Telemóvel perdido: peça ao administrador ou ao apoio da sua organização que o remova, ou use a recuperação por email.
• Apagar todos os dados da sua conta: peça-o à sua organização ou à Kotav (privacidade@authguard.pt); o efeito está descrito na secção 6.
• Desinstalar a aplicação apaga as chaves e os dados do telemóvel, mas não remove o telemóvel da conta no servidor: remova-o antes, na aplicação ou na consola.

8. Os seus direitos

Pode pedir acesso, retificação, apagamento, limitação, portabilidade e opor-se ao tratamento, junto da sua organização ou da Kotav (privacidade@authguard.pt). A exportação dos seus dados lista os seus telemóveis (nome, estado, nível de segurança e datas; nunca chaves, números de série ou tokens). Pode apresentar reclamação à Comissão Nacional de Proteção de Dados (CNPD, cnpd.pt) ou à autoridade de controlo do seu país.

9. Segurança

As chaves nunca saem do hardware seguro; cada aprovação pede a sua biometria ou o PIN do telemóvel e assina a operação exata; os ecrãs da aplicação não podem ser captados em capturas de ecrã e aparecem em branco nas aplicações recentes; as notificações não mostram o serviço nem a organização no ecrã bloqueado e não passam para relógios ligados; a aplicação não faz cópias de segurança dos seus dados.

10. Menores e alterações

A aplicação destina-se a pessoas com 18 anos ou mais, com uma conta numa organização que usa o AuthGuard. Esta política pode mudar; a data no topo indica a versão em vigor e as alterações relevantes são comunicadas na aplicação ou pela sua organização.

AuthGuard Presence for Android: privacy policy

Version of 5 November 2026. Draft for legal review. Passages marked [LEGAL REVIEW] have not yet been checked by a lawyer. The Portuguese version above prevails.

1. Who processes your data

AuthGuard Presence is the Android app that approves, on your phone, sign-ins and operations of an organization that uses AuthGuard. The app is published by Kotav International - Business and Assets, Lda (NIF 517204738), registered office at Rua Bom Jesus de Penso, 766, 4770-813 Avidos, Portugal. When the organization uses AuthGuard as a service, Kotav operates it on the organization's behalf; when the organization installs it on its own servers, the organization operates it. The organization that gave you access (usually your employer) decides how phone approvals are used and is the controller of your account data; Kotav processes it on the organization's behalf. For wake messages (FCM, section 4) Google acts as processor. [LEGAL REVIEW] Confirm the controller and processor roles and the data protection officer contact. Contact: privacidade@authguard.pt.

2. What data exists and where it stays

2.1 Only on your phone

• Two private keys per account, created in the phone's secure hardware (StrongBox or the processor's secure environment). They cannot be exported; the approval key signs only after your biometrics or the phone PIN.
• The list of linked accounts: server address, organization name, a partial account hint (for example j***@company.com), the phone's identifiers on the server, the phone name, where the keys are stored, the confirmation mode, the date the account was linked and the clock difference to the server.
• The time of the last push-token registration per account and, for 10 minutes, the identifiers of requests already notified, to avoid repeated alerts. The app does not store the token; the Firebase library keeps the token and the installation ID in the app's private storage.

This data stays in the app's private storage, excluded from backups and device-to-device transfers. Biometrics never leave the phone: the app only receives Android's confirmation that you authenticated. The camera is used only to read the linking QR code; images are analysed on the phone and neither stored nor sent.

2.2 Sent to your organization's AuthGuard server

• When linking: the two public keys, the key attestation certificate chains (issued by the phone's hardware and signed by Google), the phone name (its model, for example Pixel 8) and the key possession proofs.
• With every phone request: a proof signed by the phone's key, with the time and a random single-use identifier.
• With every decision: the decision (approve, decline or "It wasn't me"), the six-digit code you typed, inside a statement signed by the approval key, and the time.
• The Firebase Cloud Messaging (FCM) registration token, so the server can ask Google to wake the app.
• The IP address of each request, used to limit abuse (short-lived counters) and recorded in the server's access logs with the request route and without identifying the person.

The server stores for the phone: its name, the two public keys, an attestation summary (key security level, confirmation mode, Android security patch level, attestation version, app version and the SHA-256 digest of the app signing certificate), the attestation certificate serial numbers, a SHA-256 digest of the chains, and the linking, confirmation, last-use and removal times. It also records approvals and denials in the requests and in the organization's audit log.

All of these connections use TLS 1.3 with the hybrid post-quantum key exchange X25519MLKEM768.

2.3 What we do not collect

The app uses no advertising, analytics, tracking or advertising identifier. It does not read contacts, location, photos, files, the microphone or browsing history.

3. Purposes

• Authenticating you and confirming your approvals of sign-ins, administrative confirmations and operations requested by your organization's other systems.
• Binding each approval to the exact operation you saw (ProofFlow Match): the code you type on the phone must match the one the browser shows.
• Checking that the keys live in the secure hardware of an unmodified phone and that the app is the original (key attestation).
• Waking the app when a request is waiting for you.
• Preventing abuse and keeping evidence of decisions.

Legal basis: as determined by your organization, normally the performance of your contract with it or its legitimate interest in securing access (GDPR Article 6(1)(b) and (f)). [LEGAL REVIEW]

4. New-request alerts (Google Firebase Cloud Messaging)

When a request awaits your approval, the server asks Firebase Cloud Messaging, a Google service, to wake the app. The message is always the same, {"v":"1"}: it carries no request, account, organization, service, code or other content, and it expires after 5 minutes if it cannot be delivered. Once awake, the app fetches the requests directly from your organization's server over the protected channel described above and shows a notification that names only the kind of request.

For this, Google processes the FCM registration token, the Firebase installation ID, the project and app identifiers and the time and size of each message. To issue the token, the Firebase library and the phone's Google Play services contact Google and send technical data about the app and the system. Google Analytics for Firebase is off and delivery-metrics export is disabled. [TO CONFIRM ON THE PHONE] If the library sends delivery metrics of its own, they will be declared here and in the Google Play data safety form.

Google acts as processor under the Firebase Data Processing and Security Terms (firebase.google.com/terms/data-processing-terms). This data may be transferred to the United States under the transfer mechanism those terms provide (the EU-US Data Privacy Framework or the European Commission's standard contractual clauses). [LEGAL REVIEW]

Without an active account the app requests no token. Removing the last account deletes the token and turns off the automatic creation of a new one.

5. Recipients

• Your organization and its administrators, in the AuthGuard console (list of phones, state, security level, attestation summary and times; never private keys).
• When the organization uses AuthGuard as a service: Kotav, which operates it, and the hosting provider Kotav engages, in the data region the organization chooses (the European Union unless the organization chooses another). When the organization installs AuthGuard on its own servers, the data stays on those servers and Kotav does not receive it. [LEGAL REVIEW] Name the production hosting provider and the backup location, and assess the transfer if the provider or the region is not European.
• Google, for the alerts only (section 4).

The data is not sold or shared for advertising or for third parties' own purposes. The attestation revocation check downloads Google's public list without sending any data from your phone.

6. Retention

• On the phone: until you remove the account or uninstall the app.
• FCM token on the server: deleted when the phone is removed from the account or when Google reports it is no longer valid.
• Request proofs (single-use identifiers): 10 minutes, deleted by the next periodic clean-up. Approval challenges: deleted after they expire (at most 2 minutes), except those behind an approval, which stay with it. Linking requests: 7 days after they end.
• The phone's record on the server, including its name, the attestation summary and the certificate serial numbers: for as long as your account exists, also after the phone is removed, as security evidence of the approvals made with it.
• If you ask for your data to be erased (GDPR Article 17), the phone is removed, its name becomes "(removido)" and the attestation summary and serial numbers are deleted. The public keys and the SHA-256 digest of the attestation chains, needed to verify past signatures, and the audit log remain and become pseudonymous.
• Approvals, receipts and audit: according to the retention period set by your organization. [LEGAL REVIEW] Period and basis for keeping the evidence.
• Server access logs (IP address and route): 90 days.
• Backups: up to 35 days.

7. Removing this phone and your data

• In the app: "Manage accounts" › "Remove this account from this phone". The server is told and removes the phone from the account (its FCM token is deleted), and the app deletes both keys and the account's local data. Removing the last account also deletes the phone's FCM token. If the server cannot be told, the app asks you to remove the phone in the console.
• In the AuthGuard console: under "My phones", after a recent sign-in with a strong factor.
• Lost phone: ask your organization's administrator or helpdesk to remove it, or use e-mail recovery.
• Erasing all data of your account: ask your organization or Kotav (privacidade@authguard.pt); the effect is described in section 6.
• Uninstalling the app deletes the keys and the data on the phone but does not remove the phone from the account on the server: remove it first, in the app or in the console.

8. Your rights

You may request access, rectification, erasure, restriction and portability, and object to processing, through your organization or Kotav (privacidade@authguard.pt). The export of your data lists your phones (name, state, security level and times; never keys, serial numbers or tokens). You may lodge a complaint with the Portuguese data protection authority (CNPD, cnpd.pt) or the supervisory authority of your country.

9. Security

Keys never leave the secure hardware; every approval asks for your biometrics or the phone PIN and signs the exact operation; the app's screens cannot be captured in screenshots and appear blank in the recent-apps view; notifications show neither the service nor the organization on the lock screen and are not bridged to connected watches; the app does not back up your data.

10. Minors and changes

The app is intended for people aged 18 or over with an account at an organization that uses AuthGuard. This policy may change; the date at the top is the version in force, and relevant changes are announced in the app or by your organization.