Propagation of config map changes has been discussed for a long time and still not implemented: https://github.com/kubernetes/kubernetes/issues/22368

I suggest using helm upgrade process (or similar) to just rollout the same version of an app with the new settings. In this way you have additional controls: you can do a rolling update, you can rollback, you can do canary and so on.

In the following lines I'll try to exhibit an idea (It can be considered as solution, at least for the moment), it consist of mounting the configmap values as Volume,

spec:
  containers:
  - name
    ...
    volumeMounts:
      - name: config-volume
        mountPath: /etc/config   #just an example
  volumes:
    - name: config-volume
      configMap:
        name : <name-of-configmap>
        items:
          - key: <key-in-onfigmap>
            path: keys

As result we will get the value of our configMap Key inside a volume file (/etc/config/keys) we can ensure by executing theses commands

kubectl exec -it <name-of-pod> sh      #to get a shell to the running container/pod
cat /etc/config/keys                   #

Note : there a delay time from the moment when the ConfigMap is updated to the moment when keys are projected to the pod (it can be as long as kubelet ConfigMap sync period + ttl of ConfigMap cache in kubelet )

Take a look to this to make it more clear, Best regards